You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Kiran Ayyagari <ka...@apache.org> on 2010/06/30 16:16:19 UTC
[ApacheDS] changes to Authenticator interface for password policy
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
2. Am planning to make some changes to the Authenticator interface
to inject the password policy configuration
so that the authenticator can have access to this config which
needs to be used to determine whether a
user can be authenticated based on the policy state information
present in the user's entry.
The second step will change the API and I think this is the right
time to change before 2.0-RC1
let me know your thoughts about the above mentioned and as well as
about password policy implementation
(like if you think a feature xyz is good to have)
thanks for your time
Kiran Ayyagari
[1] http://tools.ietf.org/html/draft-behera-ldap-password-policy-10
Re: [ApacheDS] changes to Authenticator interface for password policy
Posted by Alex Karasulu <ak...@apache.org>.
On Thu, Jul 1, 2010 at 11:40 AM, Emmanuel Lecharny <el...@apache.org>wrote:
>
>
> On Thu, Jul 1, 2010 at 10:37 AM, Kiran Ayyagari <ka...@apache.org>wrote:
>
>> > 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).
>>
>> disabling PP is done based on the configuration, so it is not
>> intrusive. If the PP configuration
>> is not provided then the AuthenticationInterceptor skips all checks
>> related to PP.
>>
>
> That's fine.
>
> I'm not sure we want to disable the PP anyway :) As I said, it was made an
> interceptor for historical reasons, and I do think it must be part of the
> server anyway - even if no policy is set :)
>
>
OK if there is a null policy to offer the present lack of PP then I guess it
makes no difference to which way we go: PP interceptor or merged
functionality into the AuthN interceptor.
--
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
Re: [ApacheDS] changes to Authenticator interface for password policy
Posted by Emmanuel Lecharny <el...@apache.org>.
On Thu, Jul 1, 2010 at 10:37 AM, Kiran Ayyagari <ka...@apache.org>wrote:
> > 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).
>
> disabling PP is done based on the configuration, so it is not
> intrusive. If the PP configuration
> is not provided then the AuthenticationInterceptor skips all checks
> related to PP.
>
That's fine.
I'm not sure we want to disable the PP anyway :) As I said, it was made an
interceptor for historical reasons, and I do think it must be part of the
server anyway - even if no policy is set :)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] changes to Authenticator interface for password policy
Posted by Kiran Ayyagari <ka...@apache.org>.
> 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).
disabling PP is done based on the configuration, so it is not
intrusive. If the PP configuration
is not provided then the AuthenticationInterceptor skips all checks
related to PP.
Kiran Ayyagari
Re: [ApacheDS] changes to Authenticator interface for password policy
Posted by Alex Karasulu <ak...@apache.org>.
On Thu, Jul 1, 2010 at 11:32 AM, Emmanuel Lecharny <el...@apache.org>wrote:
>
>
> On Thu, Jul 1, 2010 at 10:20 AM, Kiran Ayyagari <ka...@apache.org>wrote:
>
>> On Thu, Jul 1, 2010 at 1:37 PM, Emmanuel Lecharny <el...@apache.org>
>> wrote:
>> >
>> >
>> > On Wed, Jun 30, 2010 at 4:16 PM, Kiran Ayyagari <ka...@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
Re: [ApacheDS] changes to Authenticator interface for password policy
Posted by Emmanuel Lecharny <el...@apache.org>.
On Thu, Jul 1, 2010 at 10:20 AM, Kiran Ayyagari <ka...@apache.org>wrote:
> On Thu, Jul 1, 2010 at 1:37 PM, Emmanuel Lecharny <el...@apache.org>
> wrote:
> >
> >
> > On Wed, Jun 30, 2010 at 4:16 PM, Kiran Ayyagari <ka...@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
Re: [ApacheDS] changes to Authenticator interface for password policy
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Jul 1, 2010 at 1:37 PM, Emmanuel Lecharny <el...@apache.org> wrote:
>
>
> On Wed, Jun 30, 2010 at 4:16 PM, Kiran Ayyagari <ka...@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..)
> I'm not sure that removing the interceptor is necessary at this point.
IMO this interceptor has no use anymore as the functionality is gonna
be present in
AuthenticationInterceptor (more below..)
>>
>> 2. Am planning to make some changes to the Authenticator interface
>> to inject the password policy configuration
>> so that the authenticator can have access to this config which
>> needs to be used to determine whether a
>> user can be authenticated based on the policy state information
>> present in the user's entry.
>
> 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)
> 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).
Kiran Ayyagari
Re: [ApacheDS] changes to Authenticator interface for password policy
Posted by Emmanuel Lecharny <el...@apache.org>.
On Wed, Jun 30, 2010 at 4:16 PM, Kiran Ayyagari <ka...@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).
I'm not sure that removing the interceptor is necessary at this point.
>
> 2. Am planning to make some changes to the Authenticator interface
> to inject the password policy configuration
> so that the authenticator can have access to this config which
> needs to be used to determine whether a
> user can be authenticated based on the policy state information
> present in the user's entry.
>
The authentication is not impacted by the passwordPolicy AFAICT.
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com