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 ?
>
>> 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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
