Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 93484 invoked from network); 1 Jul 2010 08:32:43 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Jul 2010 08:32:43 -0000 Received: (qmail 71229 invoked by uid 500); 1 Jul 2010 08:32:43 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 71018 invoked by uid 500); 1 Jul 2010 08:32:40 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 71004 invoked by uid 99); 1 Jul 2010 08:32:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Jul 2010 08:32:39 +0000 X-ASF-Spam-Status: No, hits=-1997.8 required=10.0 tests=ALL_TRUSTED,HTML_MESSAGE,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 01 Jul 2010 08:32:36 +0000 Received: (qmail 93071 invoked by uid 99); 1 Jul 2010 08:32:13 -0000 Received: from localhost.apache.org (HELO mail-fx0-f50.google.com) (127.0.0.1) (smtp-auth username elecharny, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Jul 2010 08:32:13 +0000 Received: by fxm9 with SMTP id 9so1293072fxm.37 for ; Thu, 01 Jul 2010 01:32:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.17.150 with SMTP id s22mr8981215faa.14.1277973129878; Thu, 01 Jul 2010 01:32:09 -0700 (PDT) Reply-To: elecharny@apache.org Received: by 10.223.113.2 with HTTP; Thu, 1 Jul 2010 01:32:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Jul 2010 10:32:09 +0200 Message-ID: Subject: Re: [ApacheDS] changes to Authenticator interface for password policy From: Emmanuel Lecharny To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=001517476344705ef2048a4f4e25 X-Virus-Checked: Checked by ClamAV on apache.org --001517476344705ef2048a4f4e25 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 1, 2010 at 10:20 AM, Kiran Ayyagari wrote= : > On Thu, Jul 1, 2010 at 1:37 PM, Emmanuel Lecharny > wrote: > > > > > > On Wed, Jun 30, 2010 at 4:16 PM, Kiran Ayyagari > > 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 implementati= on > >> > >> 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 t= he > > 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 presen= t 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 t= he > 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 > --=20 Regards, Cordialement, Emmanuel L=E9charny www.iktek.com --001517476344705ef2048a4f4e25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 1, 2010 at 10:20 AM, Kiran A= yyagari <kayya= gari@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,
>>
>> =A0Its been a while since I started working on implementing passwo= rd
>> policy[1].
>>
>> =A0Here are a few things I wanted to let you know about the implem= entation
>>
>> =A0 1. The PasswordPolicyInterceptor cannot be used to enforce thi= s
>> policy cause we need access to the
>> =A0 =A0 =A0 userpassword and other special attributes before the >> authentication process starts, so am removing this
>> =A0 =A0 =A0 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= .
=A0
> The authentication is not impacted by the passwordPolicy AFAICT.
it gets impacted in cases like
=A0a. expired password
=A0b. 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 po= ssible.

The question is more or less about the PP = being a part of the authent process, or if we want to have a separate modul= e just to have a distinct processing for the PP (this could make sense if w= e want to disable the PP).

The reason why the PP interceptor is separate atm is th= at it was not present at the origin, and was added after. The Intecreptor c= hain allows us to have such a separation, and it was easy to add featuers t= his way.

Now, I'm not sure it makes sense to make a distinct= ion 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).


=A0
> PP is a matter of controlling that the password resp= ect some conditions when
> added or modified (it's controlled for the Add and Modify operatio= n only).
> Otherwise, the PP is transparent.
it is not just add and modify but also the bind, cause this is where<= br> 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 credential= s against the PP, we should then merge those two interceptors.=A0

Kiran Ayyagari



--
Regards,
Cord= ialement,
Emmanuel L=E9charny
www.ik= tek.com
--001517476344705ef2048a4f4e25--