On 5/6/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
... hey, thanks for all this code ! We now have to check it before merging it, and we will do it this week, so that we will be both ready at the same time to merge the code into the trunk ! <snip/>
One thing to watch for is that AES256 requires "unlimited strength" policy in the JRE. I tried to make sure to handle its absence gracefully and to comment-out relevant unit tests. But, I haven't tested it on any platforms except Linux or VM's except Sun. I think this branch (encryption types) should merge in before the SASL branch. Once the new encryption types are in trunk, I'd like to revisit the SASL branch since there is some interop with SASL GSSAPI and Kerberos that I'd like to ensure is working.
> The interceptor works great whether the 'userPassword' is changed over > the LDAP protocol, by the ChangePassword protocol, or by LDIF load. > This is a testament to the interceptor service chain in the core. The > interceptor will make working with Kerberos principals much easier. Just great ! I can't wait to see all that alive in trunks ! Ok, svn co kerberos-branch running :)
The more I think about it, the more I'd like to get a password policy interceptor in there. Now that key derivation/generation is centralized, it makes even more sense to centralize password policy enforcement. There is a basic password policy validator in the Change Password and I'd like to convert this to an interceptor. I'm thinking I would model it after the AuthenticationService, w.r.t. how Authenticators are "pluggable." I would commit a policy validator based on the one in Change Password and we'd have this extension point available for other custom policies. Also, I'm going to start in on "key export" now, re: Realm Control Initiatives [1]. Enrique [1] http://cwiki.apache.org/confluence/display/DIRxSBOX/Realm+Control+Initiatives
