directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Extending Authentication for Bind
Date Fri, 22 Feb 2013 12:21:27 GMT
Le 2/22/13 12:34 PM, Kiran Ayyagari a écrit :
> On Fri, Feb 22, 2013 at 3:08 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote:
>
>> Le 2/22/13 9:11 AM, Kiran Ayyagari a écrit :
>>> On Thu, Feb 21, 2013 at 11:29 PM, Emmanuel Lécharny <elecharny@gmail.com
>>> wrote:
>>>
>>>> Le 2/21/13 6:54 PM, Kiran Ayyagari a écrit :
>>>>> On Thu, Feb 21, 2013 at 11:10 PM, Emmanuel Lécharny <
>> elecharny@gmail.com
>>>>> 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 


Mime
View raw message