I am trying to do user authentication using Apacheds Server. For that I am using Password Policy defined. Most of the authentication requirements are met using these policies, but one thing I am not able to do is password pattern. Is there a way to check if user password meets with particular pattern requirements. Requirements I need are:
Uppercase character
Lowercase character
number
special character
You need to provide a custom PasswordValidator to achieve this. See DefaultPasswordValidator if you need an implementation sample.
Related
I'm new in LDAP. Perhaps the question may seem strange, but on the internet I have seen different versions. Please, help to understand which way is the correct authentication via LDAP. I have an LDAP-directory where user passwords are stored as hashes. I know two ways to authenticate third-party applications using the LDAP-directory:
Authentication check on the LDAP side. Using the “bind” function the DN and password of user are passed in plain-text. If the bind is successful user authenticate, otherwise doesn't.
Authentication check on the application side. Using the function “bind” we connect to the directory as an admin. We are looking for the right user and get his record. We parse password field, isolating the type of hash algorithm (e.g. {CRYPT}). We make hash of the user-entered password with proper algorithm. If the hashes are the same then the authentication is successful, otherwise not. (That is, the application must maintain an appropriate hash algorithm).
Which option is the most correct? And which way is considered a standard for any-vendor systems which claim support for LDAP-authentication?
You'll want to use Option 1!!!!!
Option 2 has some disadvantages:
You'll need an admin account that can read the passwords to be able to compare them to the one you hashed. That means that the application is able to read the password hashed. I'd consider that a bad idea.
You'll circumvent additional security measurements implemented. The password you are checking might be the right one. But due to other policies the user might be locked and should not be able to login. And failed attempts will not count towards a possible lockout.
The hashing algorithm might change in future to one you haven't implemented yet.
You might be able to circumvent those obstacles but you will need aditional code to implement that. And that effort has already been taken and is readily availabel when you use option 1
We have achieved internationalization in the application, but now we want to have support for user can enter password in his own language(Arabic, Russian, Chinese) etc. Here the problem is validation gets fail for upper case and lower case characters. So, please help me provide standard validations rules or password policy which can be applied to authenticate user from any language.
I've looked at this many years ago, and I've been told that most of the users are using Password that are ascii characters, because it's not possible to compose complex characters (Kanji) without displaying them on the screen.
Also the new recommendations from NIST is to stop trying to impose specific characters, but just enforce a minimal length of at least 8 characters, and check against a dictionary of known compromised passwords.
I have set up a Ldap Server somewhere. I can bind to it, can add, modify, delete entry in the database. Now when it come to authentication isnt it as simple as giving the username and password to the server, asking it to search for an entry matching the two? And furthermore, isnt it the 'userPassword' field that contains the password for a user in there?
Now,
I tried to set up splunk to authenticate from my Ldap server, i provided the username and password, but it failed authentication. Isnt it that 'userPassword' field that splunk checks? What should be the possible reason?
LDAP servers are generally not going to allow you to search on the userPassword attribute, for obvious security reasons. (and the password attribute is likely stored in hashed form anyway, so a straight search would not work.)
Instead, the usual way to do LDAP authentication is:
prompt for username & password
Bind to LDAP with your application's account, search for username to get the full distinguished name (dn) of the user's LDAP entry
Make a new LDAP connection, and attempt to bind using the user's dn & password
(If you know how to construct the dn from the username, you can skip step 2, but it's generally a good idea to search first - that way you're less sensitive to things like changes in the OU structure of the LDAP directory)
Typically you would search using the username value provided on uid or cn values within the LDAP Tree.
-jim
I think this code will help you resolve the issue of authentication. I've answered to resolve the issue. You can check out this Question http://bit.ly/TIJMte
I'm interested in how other people code this because I'm either not understanding it properly or I'm missing something or perhaps even I'm doing it right!
First of all, this is NOT an Active Directory instance of LDAP its OpenDS which other than some syntactical differences shouldn't much matter.
So assume I have my tree structure setup something like this:
-dc=somedomain,dc=com
-uid=rootuser
-ou=Group1
-uid=username1
-uid=username2
-ou=Group2
-uid=username3
-uid=username4
In order to authenticate as the 'rootuser' I would need to pass the fully qualified Username when I create my System.DirectoryServices.DirectoryEntry object, in this case:
uid=rootuser,dc=somedomain,dc=com
but for any other user in the tree I have to know in advance what LDAP path to append to the username to have them authenticate thru. So for example this will fail:
uid=username1,dc=somedomain,dc=com
but this will work:
uid=username1,dc=somedomain,dc=com,ou=Group1
So my question is how do you handle this when you don't know at login time what specific group a user belongs to to build that path? The only way I can figure to do it is to make the initial call as 'rootuser' so I have access to the entire tree then use System.DirectoryServices.DirectorySearcher to scan it for that particular user (i.e. username1)
using (DirectorySearcher searcher = GetDirectorySearcher()) {
searcher.Filter = "(&(objectClass=person)(uid=" + userName+ "))";
SearchResult result = searcher.FindOne();
return result.GetDirectoryEntry().Path;
}
at that point I have the path for the user I want to login and I can proceed with the actual auth. Am I way off base here or is this generally how it is done?
thanks!
You build a search filter on attributes that are unique to the user, e.g. screen-name, e-mail. Make sure LDAP is configured to ensure they are unique. Then you find the corresponding entry if any, get the DN, and rebind as that user with the appropriate password. If there was no such entry you react accordingly.
You don't say what language you are using, but in JNDI that means setting the DN as the security principal, the password as the credentials, and calling LdapContext.reconnect().
SASL supports the notion of using a username to authenticate. Your directory server administrator may be able to configure the directory server to map distinguished names to identities. Given the correct mapping it is possible for a client to authenticate without knowing the distinguished name. Professional-quality directory servers support a number of different mapping mechanisms such as direct mapping, exact match, regular expression, or a custom identity mapper.
I am using OpenID authentication in conjunction with traditional register/signin authentication on a site of mine. When someone signs in for the first time using OpenID, I would like to be able to extract a username for use on the site.
This is easy for some openid identifiers - eg:
http://username.myopenid.com/
http://username.livejournal.com/
http://claimid.com/username
However this isn't always the case as any URL can essentially be used as an OpenID.
One option is to maintain a list of URL formats as above where I know I can extract a username - and auto-assign a username in the other cases (which can be changed after signing in). Is there any other, more flexible way of extracting a username?
This tutorial seems to cover what you want and more attributes.
OpenID has an API for getting user information like a name, email and so on. I'd just use the name if the user allows you to access it.
Since OpenID is an authentication which works without username/password outside of the OpenID authenticating site but just with the URL, it is per se not possible to extract an unique username.
I think, that guessing an username from the url or auto-assigning one if the guessing is not possible (eg. Google) is the best you can get. Sorry.