On Fri, Feb 22, 2013 at 5:51 PM, Emmanuel Lécharny <[email protected]>wrote:
> Le 2/22/13 12:34 PM, Kiran Ayyagari a écrit : > > On Fri, Feb 22, 2013 at 3:08 PM, Emmanuel Lécharny <[email protected] > >wrote: > > > >> Le 2/22/13 9:11 AM, Kiran Ayyagari a écrit : > >>> On Thu, Feb 21, 2013 at 11:29 PM, Emmanuel Lécharny < > [email protected] > >>> wrote: > >>> > >>>> Le 2/21/13 6:54 PM, Kiran Ayyagari a écrit : > >>>>> On Thu, Feb 21, 2013 at 11:10 PM, Emmanuel Lécharny < > >> [email protected] > >>>>> wrote: > >>>>> > >>>>>> Le 2/21/13 5:25 PM, Kiran Ayyagari a écrit : > >>>>>>> don't think we have such a support right now do we? is that looping > >> of > >>>>>>> authenticators makes this a possibility? > >>>>>> I see that the Authenticator interface provide a checkPwdPolicy() > >>>> method : > >>>>>> /** > >>>>>> * performs checks on the given entry based on the specified > >>>>>> password policy configuration > >>>>>> * > >>>>>> * @param userEntry the user entry to be checked for > >> authentication > >>>>>> * @throws PasswordPolicyException > >>>>>> */ > >>>>>> void checkPwdPolicy( Entry userEntry ) throws LdapException; > >>>>>> > >>>>>> Why can't we do all the passwordPolicy checks in the authenticator, > >>>>>> instead of the interceptor ? > >>>>>> > >>>>>> The only pb is that we need the user entry at this point, but > couldn't > >>>>>> we pass the BindContext, so for the checkPwdPolicy() to fetch the > >> entry > >>>>>> from the DS instead ? > >>>>>> > >>>>>> Does it make sense ? > >>>>>> > >>>>>> password policy is enforced not only during authentication but also > >>>> after > >>>>> authentication and while doing modify operation > >>>> Absolutly, but here, I'm just mentioning the check when doing a bind. > >>>> Every other operation should be done in the interceptors. > >>>> > >>>> we still need to perform several checkes during and after > authentication > >>> in the same bind operation > >>> so we cannot move this logic entirely to authenticators > >>> > >> The thing is that we may not need the entry to do those checks. If we > >> do, then it's a problem, because that means we can't delegate > >> authentication... > >> > >> no we can bypass this by overriding the checkPwdPolicy() method (the > > DelegatingAuthenticator does just that) > > It's sadly not enbough. In the AutenticationInterceptor.bind() method, > we do : > > Dn dn = bindContext.getDn(); > Entry userEntry = bindContext.getEntry(); > > PasswordPolicyConfiguration policyConfig = getPwdPolicy( > userEntry ); > > and the getPwdPolicy() method does : > > public PasswordPolicyConfiguration getPwdPolicy( Entry userEntry ) > throws LdapException > { > if ( pwdPolicyContainer == null ) > { > return null; > } > > if ( pwdPolicyContainer.hasCustomConfigs() ) > { > Attribute pwdPolicySubentry = userEntry.get( > pwdPolicySubentryAT ); > > if ( pwdPolicySubentry != null ) > { > Dn configDn = > adminSession.getDirectoryService().getDnFactory().create( > pwdPolicySubentry.getString() ); > > return pwdPolicyContainer.getPolicyConfig( configDn ); > } > } > > return pwdPolicyContainer.getDefaultPolicy(); > } > > > So here, you'll get a NPE if the pwdPolicyContainer as some custom config. > > Attribute pwdPolicySubentry = userEntry.get( > pwdPolicySubentryAT ); // usrEntry is null > > But we can fix that easily. > > My point is that the next code : > > if ( policyConfig != null ) > { > LookupOperationContext lookupContext = new > LookupOperationContext( adminSession, bindContext.getDn(), > SchemaConstants.ALL_ATTRIBUTES_ARRAY ); > userEntry = directoryService.getPartitionNexus().lookup( > lookupContext ); > } > > is useless if we have a delegated authentication : why should we lookup > for the user entry when we know it's not present ? > > > Well, so to speak, it will work, but it might worth some improvement, IMO. > > wdyt ? > > > yes, we need a flag to bypass this > > > > > > >> So we have to find a way to avoid requesting the entry. > >> > >> What are the checks we need to do btw ? (I've not spent much time on > >> this part of the code...) > >> > >> it does password expiration, grace logins, locking/unlocking and checks > > if the password is ready for use based on the activation time > > Such checks can't be done if the user is external, no ? > > yes, just mentioned what the code in authenticator does > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > -- Kiran Ayyagari http://keydap.com
