directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: [ApacheDS] changes to Authenticator interface for password policy
Date Thu, 01 Jul 2010 08:32:09 GMT
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 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).




> > 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.

>
> Kiran Ayyagari
>



-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message