> On Sep 20, 2022, at 3:25 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>
>
> After a first pass through the ApacheDS issues, and a removal of some of them
> (down to 379 from 410 issues), I'm going to work on the PasswordPolicy part
> of the server. On eof the reason is that 17 issues are related to this part,
> and also because there is some inconsistency in the way we deal with
> transaction when updating some entries, causing some JDBM breakage.
>
> There is also a new version for the PasswordPolicy draft [1] and it would be
> useful to have our implementation folloiwng the few changes.
>
> Here is how I'll process:
> - First review the existing logic, wrt the RFC draft.
> - Then probably create a dedicated interceptor, which will be set before the
> authentication interceptor: there is no technical or functionnal reason to
> mix those two interceptors AFAICT, that makes the code more complex to
> implement.
>
> There are 3 areas where I think I will not follow the draft, at least in this
> version:
> * The userPassword attribute is not considered as the only one that can
> contain some password. There is an attributeType that is defined which gives
> the list of attribute that may contain the password. I think a first step is
> to ignore that value. Once it works, going further should not really be such
> a pain...
Agreed, renaming pw attribute is limited, if not dubious value.
> * It's mentionned that some PasswordPolicies may be defined as subentries,
> and we may even define some administrativeRole to define the part of the DIT
> that is subject to this subentry. Again, a first implementation should focus
> on having the global PasswordPolicy working. Defining an AdminsitrativeRole
> induce some complexity that I'd rather move away atm.
Just a few words in favor of this. For example, min age. When a user entry is
created, they may need an admin reset. If the min age is long duration the
admin will be prevented.
Having said that, it’s still a bit of a corner case. I’m sure there are other
reasons though.
Having said that, this work should progress at a comfortable pace, so I’m good
with a phased approach.
> * Last not least, and it relates to the first point, I will not handle the
> attributeType option used to defined with password attribute is impacted by a
> PasswordPolicy rule. For instance:
>
> pwdChangedTime;pwd-userPassword: 20000103121520Z
>
> will not be taken into account now.
>
> Feel free to comment !
I’m +1 on this work. My goal is to update fortress to follow, adding tests for
verification.
Thanks
—
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
