directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [ApacheDS] changes to Authenticator interface for password policy
Date Thu, 01 Jul 2010 21:45:00 GMT
On Thu, Jul 1, 2010 at 11:32 AM, Emmanuel Lecharny <elecharny@apache.org>wrote:

>
>
> On Thu, Jul 1, 2010 at 10:20 AM, Kiran Ayyagari <kayyagari@apache.org>wrote:
>
>> On Thu, Jul 1, 2010 at 1:37 PM, Emmanuel Lecharny <elecharny@apache.org>
>> wrote:
>> >
>> >
>> > On Wed, Jun 30, 2010 at 4:16 PM, Kiran Ayyagari <kayyagari@apache.org>
>> > wrote:
>> >>
>> >> hello guys,
>> >>
>> >>  Its been a while since I started working on implementing password
>> >> policy[1].
>> >>
>> >>  Here are a few things I wanted to let you know about the
>> implementation
>> >>
>> >>   1. The PasswordPolicyInterceptor cannot be used to enforce this
>> >> policy cause we need access to the
>> >>       userpassword and other special attributes before the
>> >> authentication process starts, so am removing this
>> >>       interceptor
>> >
>> > You can access those elements in the intereceptor : the modified entry
>> is
>> > already loaded when the interceptor is processed (we do a load of all
>> the
>> > modified entry fields before going through the chain).
>> we have access to the entry but we need them before we start
>> authenticaing, (more below..)
>>
>
> You have those informations when you start entering into the chain. So
> that's ok.
>
>
>>  > The authentication is not impacted by the passwordPolicy AFAICT.
>> it gets impacted in cases like
>>  a. expired password
>>  b. locked account
>> in both of these cases we refuse to authenticate the user
>> (irrespective of the passed credentials)
>>
>
> I see your point.
>
> Here, we have two options :
> - merge the PP interceptor into the Athn interceptor (this is what you
> propose)
> - have the PP interceptor being processed after the authn, which is
> possible.
>
>
The second option sounds attractive cuz you can just remove the interceptor
if you like. I guess we can use settings as well to disable the PP code but
the second option seems better.


> The question is more or less about the PP being a part of the authent
> process, or if we want to have a separate module just to have a distinct
> processing for the PP (this could make sense if we want to disable the PP).
>
> The reason why the PP interceptor is separate atm is that it was not
> present at the origin, and was added after. The Intecreptor chain allows us
> to have such a separation, and it was easy to add featuers this way.
>
> Now, I'm not sure it makes sense to make a distinction between the PP and
> auth interceptrs at this point, if we consider that PP is a part of the
> server (ie, it can't be disabled).
>
>
I think some people will not want it and have a knee jerk reaction even
though it's a best to have proper PP.


>
>
>
>> > PP is a matter of controlling that the password respect some conditions
>> when
>> > added or modified (it's controlled for the Add and Modify operation
>> only).
>> > Otherwise, the PP is transparent.
>> it is not just add and modify but also the bind, cause this is where
>> we handle the above
>> mentioned cases so the best place to have this policy implementation is
>> the
>> AuthenticationInterceptor and in the AbstractAuthenticator(for
>> checking the locked or expired
>> passwords before authenticating).
>>
>
> Ok, I see. IMO, cnsidering that the Bind operation needs to check the
> credentials against the PP, we should then merge those two interceptors.
>

Not necessarily. Even if authentication passes the AuthenticationInterceptor
bind() the PP interceptor if placed after the authN should fail causing the
bind operation to fail. Or am I missing something here?

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Mime
View raw message