On Thu, Jul 1, 2010 at 11:32 AM, Emmanuel Lecharny <[email protected]>wrote:
> > > On Thu, Jul 1, 2010 at 10:20 AM, Kiran Ayyagari <[email protected]>wrote: > >> On Thu, Jul 1, 2010 at 1:37 PM, Emmanuel Lecharny <[email protected]> >> wrote: >> > >> > >> > On Wed, Jun 30, 2010 at 4:16 PM, Kiran Ayyagari <[email protected]> >> > 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
