I am looking for a simple way to create a "realm" within WAS 8.5. I am specifically looking for something similar to the APACHE realm system in which a user, upon first access to a site, is presented with a javaScript username / password dialog and, if authenticated, is allowed to use the site. In Tomcat, this is accomplished by modifying the tomcat-users.xml file, adding a username, passowrd and role. Any suggestions are appreciated.
In WebSphere it is already built in, you just need to configure repository from where you want to take users e.g internal file based, or LDAP.
Than you need to enable Application security via Global Security.
Check this page for more details Enabling security
I followed these steps to implement basic authentication. http://itcareergrowth.com/blog/2018/02/25/configuring-basic-authentication-in-web-sphere-application-server/#.WpQiSOdMGUk
I have successfully assembled over a half dozen passport strategies (facebook, twitter, linkedin, instagram, tumblr, google, youtube) exchange account info with oauth1 and oauth2 token, into a single standalone auth server that saves session in Mongo and creates active profiles, with token/session/code/id fields and with many standardized atribute fields in SQL server using Tedious.js. These passport tools are excellent, thank you.
My last challenge for this project is not going as well, username and password into an active directory repository, to look up and auth in the same way. I have been trying over and over again passport-ldap, passport-ldapauth (based on ldapauth-gfork, based on ldapjs), passport-windowsauth and passport-kerberos, and seem to be getting related credential errors (deep in code, adding console.logs to try and figure out what I am getting syntactically wrong).
Are there any other resources and documentation to accessing LDAP/AD in Node.js using any strategy of Passport? The DN versus ou syntax and where the account access user (have a service account specifically set up to access the AD) for the repository versus the account user you are looking up and the filters make it very difficult to find anything error related to figure out where I am going wrong. Do you match to sAMAccountName or uid? I keep consistently getting "unauthorized" errors.
Unlike the other 70 passport strategies, where the doc and examples are clear and just work, not so much for ad/ldap passport. Can anyone point me to a good test, doc or setup that works well specifically with Passport.js and Active Directory?
While this is an old question I thought, as the maintainer of passport-ldapauth, I should clarify LDAP authentication a little.
LDAP authentication is different from those strategies you've used before. Those OAuth strategies can really be configured only one way - provide the required options, and then it works. This part is the same with LDAP, but the actual values to the options differ from one server to the other. The questions you are asking, like do you match to sAMAccountName or uid, are really up to you and the LDAP server.
General things like what does a DN look like, what is search base, or what is the syntax of search filter have been defined extensively in RFCs. If one is not familiar with the basics it can be difficult to get the authentication to work. Often the AD/LDAP server maintainer input is needed to have proper settings, eg. what search base allows finding all required users but does not cause unnecessary load on the LDAP server.
LDAP authentication usually works in three steps:
Using a service account (in passport-ldapauth, bindDn and bindCredentials), bind against the LDAP server.
Once bound, perform the configured search substituting the placeholder with user provided username. This determines if the given username is found from the LDAP server.
Use the DN of the search result, together with user provided password, and bind against the LDAP server. This verifies the password.
If you wish to have users login using their SAMAccountName, your search filter could be eg. (sAMAccountName={{username}}). If you wish that the users use uid, the filter could be just (uid={{username}}). If you want to enable both, use (|(sAMAccountName={{username}})(uid={{username}})). The search filter syntax is specified in RFC 4515.
I was able to authenticate to AD via passport-ldapauth.
One key was knowing to use server opts which are different than in some LDAP examples online
searchBase: 'ou=Accounts,dc=mydomain,dc=com'
searchFilter: '(sAMAccountName={{username}})' // {{username}} comes from the html form.
You also need to know if you need ldaps and TLS or not. (I did not) I spent a good amount of time digging through ldapjs.org.
Microsoft have released an official library for this:
https://github.com/AzureAD/passport-azure-ad
Add to your project from npm directly:
npm install passport-azure-ad
Or Auth0's passport-azure-ad-oauth2 for OAuth2 flows.
I am not sure how flexible you are with your requirements, but I was researching the same subject and stumbled upon a specific solution from Microsoft that uses AD FS as an Oauth provider
https://msdn.microsoft.com/en-us/library/dn633593.aspx
A superficial reading shows that a web client contacts AD to get a JWT token, then this token is sent to your server, which then authenticates the token with the AD server.
The AD server needs to be configured to accept your server as a relying party that needs its identity service.
I am a consultant. The company that I am doing work for has given me limited access to a couple servers. I do not have permission to log on to the ldap server.
I am using the following to bind:
(sAMAccountName={{username}})
If I cannot physically log on to the ldap server am I not able to authenticate via ldap?
If they give me access to log on to the server, ldapauth works.
Gina
I'm developing an application with Grails.
Im trying to implement an SSO-functionality. But I can't authenticate the users via windows session, because some of them has another windows passwort as the domain password.
(I retrieve the users via LDAP) So, how can I authenticate them?
Scenario should be following:
User goes to the Grails-Site
Popup appears where the users has to fill in with his credentials
After that, he has never to authenticate again...
Does anyone of you has some experience with it?
I think if you need SSO for many grails applications a good choice is to add saml support to your grails applications using this plugin and then build an IdP (there are many in many languages) and connect the IdP to your ldap.
SAML is standard and is the future.
If you need more info about saml check the saml entry at wikipedia. There you can find links to documentation and software.
We are setting up a portal based on Liferay at the same time we are moving our insitution's intranet onto Tridion CMS.
Tridion is using google mini as its search tool, while Liferay is using lucene.
What we want is a single search that indexes both systems.
The big issue for us is that Liferay is using CAS for authentication and we are not sure how to get google mini authenticated into liferay.
I have the same problem. I am going to create a service-api-admin account in liferay and add an additional authentication AutoLogin via the auto.login.hooks property (in portal-ext.properties). That authenticator will use the liferay database password value to verify the service-api-admin account without going through CAS so you will be able to supply authentication with your REST calls.
You can set LDAP for Liferay and Google mini can LDAP too.
I need to implement the Win2k3 password validation policy. As my application resides on Win2k3 cane we validate the password directly with windows domain password by using LDAP. This is because application design does not want to store 8/more password entry into DB and validate new password against that. As Windows already does same thing and using LDAP we can lookup into windows server.
Can any one please let me know LDAP API to fulfill above requirement in VC++.
There is an API that Secure Ops, Novell's Identity Manager, and other products use to plugin to the password change functionality. (I do not know the API name, sorry).
It requires a password filter installed on each domain controller, since the only time it can catch the clear text password to try and do anything with it is when it is being changed, and it might be changed on any given DC at any moment in time.