Jørgen Løkke (Migrated from SEC-214) said:
Add functionality to be able to use LDAP password policy request/response controls as described in:
Extract from the draft’s abstract:
“..In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and users are locked out after a certain number of failed attempts.”
The implementation has been discussed in the current thread: http://forum.springframework.org/showthread.php?t=21860 and Luke has added related classes to the sandbox. Necessary classes are still missing.
1. org.acegisecurity.providers.ldap.DefaultInitialDirContextFactory return instances of InitialDirContext. To be able to use request controls the returned contexts needs to implement LdapContext. I suggest adding a new factory DefaultInitialLdapContextFactory or rewriting the existing factory to return instances of InitialLdapContext instead of InitialDirContext. The factory should also include these methods:
a) void setConnectionRequestControls(javax.naming.ldap.Control controls);
These controls are used when instanciating the returned contexts.
b) void setControlFactories(String factories);
A convenience method which sets the environment property for specifying the list of control factories to use.
2. Create an authenticator which is password policy aware.
Luke Taylor said:
This almost certainly won’t make it into 1.0, largely because it’ll be difficult to write tests. The changes made for SEC-264 now make it possible to return a full UserDetails object from the authenticator (and controls if required) so I’ll be lookeng into it post 1.0
Ben Alex said:
Luke, can we close this off and treat it as part of the Ldap Template migration (SEC-449)?
It’s not really related to spring ldap.
There has been a contribution in this area which should be reviewed
I've added a PasswordPolicyAwareContextSource which makes use of ctx.reconnect() in order to pass a password policy control during a bind operation (and retrieve it afterwards). This seems to be the only way you can retrieve the control and detect a locked account, even if an exception occurs, without resorting to an alternative API than the standard JNDI one offered by the JDK. BindAuthenticator is now aware of the control and will add it as an attribute to the DirContextAdapter it returns, keyed under the control OID. The default context mapper which creates LdapUseDetailsImpl objects also accesses the data and the time to passwod expiry/grace logins can be read directly from the returned principal by casting it to PasswordPolicyData. LdapAuthenticationProvider detects locked accounts and converts the throws PasswordPolicyException to a standard Spring Security LockedException.
Relevant classes are in the org.springframework.ldap.ppolicy package. I've also added some tests which make use of OpenLDAP test data. There's a slapd startup script in the ldap module directory which must be started to run these tests (they have to be run manually).
carlos santillan said:
I have already configured with password policy_overlay with Spring Security 3.0.3 and i'm not receiving LockedException. I can test after 3 failed attempts an account locked but the error Message said "BadCredentialsException" instead "AccountLockedException". Could you provide me an example of your slapd.conf and spring security in order to allow throw right exception.
Thanks in advance