From dev-return-34420-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Thu Jul 01 21:46:29 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 3534 invoked from network); 1 Jul 2010 21:46:29 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Jul 2010 21:46:29 -0000 Received: (qmail 61424 invoked by uid 500); 1 Jul 2010 21:46:29 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 61328 invoked by uid 500); 1 Jul 2010 21:46:28 -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 61321 invoked by uid 99); 1 Jul 2010 21:46:28 -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 21:46:28 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 209.85.161.50 as permitted sender) Received: from [209.85.161.50] (HELO mail-fx0-f50.google.com) (209.85.161.50) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Jul 2010 21:46:21 +0000 Received: by fxm9 with SMTP id 9so2256788fxm.37 for ; Thu, 01 Jul 2010 14:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=JHYLazPojw94I5IZkJh9DUOkJ6OoCkNC6a5WcCktydk=; b=JXqVPLggkUz1tePbXmRf044TZMvx9oywZkqEHJl7WSu+6jHh82dd8TCJEkBvx4eGih nfs3/BHyubI8SIka6r5ZOubhGnBly/JFMw45bg2yyJ5Qmk9V5roeCWDgOz2XJ8ezpGui Gtyj9QTbmyx5uV2FoXUCChG49AnqkK19Gr+X0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=FeEH91/4i+xYB1lyzpVpreFeN12Ket3xAEYx3i9wX3XljBCR4e8ULX+ChUhhNw1gXA S2VUcxIm9YCqclUYWDyr3RKgz3zJ7dkSbzu8KfABB0f8W2FUwUl98DqLsKxqj41Me3eE F6XVAuIC6p+H1ITeAg7g9UU7zAxX95vOwFz8g= MIME-Version: 1.0 Received: by 10.239.168.8 with SMTP id i8mr4708hbe.179.1278020700738; Thu, 01 Jul 2010 14:45:00 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.239.133.197 with HTTP; Thu, 1 Jul 2010 14:45:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Jul 2010 00:45:00 +0300 X-Google-Sender-Auth: 1BMuQBa4FEXtixSj-6cY6pt_s1k Message-ID: Subject: Re: [ApacheDS] changes to Authenticator interface for password policy From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=001485f80e84e2150f048a5a6176 X-Virus-Checked: Checked by ClamAV on apache.org --001485f80e84e2150f048a5a6176 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 1, 2010 at 11:32 AM, Emmanuel Lecharny wrote: > > > 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 >> 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 --001485f80e84e2150f048a5a6176 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 1, 2010 at 11:32 AM, Emmanue= l Lecharny <el= echarny@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> wrot= e:
>
>
> 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= 9;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 option= s :
- 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 seco= nd 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 se= cond option seems better.
=A0
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 di= stinct processing for the PP (this could make sense if we want to disable t= he 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).


I think some pe= ople will not want it and have a knee jerk reaction even though it's a = best to have proper PP.
=A0

=A0
> PP is a matter of controlling that the password respect some cond= itions 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 cred= entials against the PP, we should then merge those two interceptors.

Not necessarily. Even if authenticat= ion passes the AuthenticationInterceptor bind() the PP interceptor if place= d after the authN should fail causing the bind operation to fail. Or am I m= issing something here?

--=A0
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
--001485f80e84e2150f048a5a6176--