You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2022/09/20 20:25:53 UTC
PasswordPolicy review
Hi!
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...
* 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.
* 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 !
Thanks!
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: PasswordPolicy review
Posted by Emmanuel Lécharny <el...@gmail.com>.
A correction (in line, at the end)
On 2022/09/30 10:48, Emmanuel Lécharny wrote:
> Hi Shawn,
>
> On 2022/09/29 16:57, Shawn McKinney wrote:
>>
>>
>>> On Sep 29, 2022, at 8:11 AM, Emmanuel Lécharny <el...@gmail.com>
>>> wrote:
>>>
>>>>> * 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.`
>>>
>>> I'm nut sure I get what you mean... I don't see a valid reason to do
>>> an admin reset when a user is created. Admin will create the user,
>>> and we may have a request for the user to change its password, but it
>>> may be unrelated to what you wrote. What is the min age has to do
>>> with the fact we don't implement administrativeRoles ?
>>>
>>> VCan you clarify?
>>
>> Let’s take an example pw policy:
>>
>> - name: default
>> sn: 'default'
>> cn: 'default'
>> description: 'test ppolicy'
>> pwdAttribute: userPassword
>> pwdAllowUserChange: 'TRUE'
>> pwdSafeModify: 'FALSE'
>> pwdInHistory: 5
>> pwdCheckQuality: 2
>> pwdMinLength: 6
>> pwdMinAge: 86400
>> pwdExpireWarning: 2880
>> pwdGraceAuthNLimit: 0
>> pwdLockout: 'TRUE'
>> pwdFailureCountInterval: 600
>> pwdMustChange: 'FALSE'
>> pwdLockoutDuration: 300
>> pwdMaxFailure: 5
>> pwdMaxAge: 94608000
>>
>> Which is set as the default for the directory.
>>
>> Here the minAge is set to 1 day. Next we create a user entry via some
>> automatic mechanism.
>
> So here this is a creation. This does nit count as a modification
> (reminder: Password Change is a Password Modify Operation operation when
> the current user performs the Password Change)
>
> For whatever reason the new user doesn’t know the password and
> requests a reset before 1 day has elapsed.
>
> The first modification should pass. The second won't.
>
>
> So, the admin attempts a pw reset but can’t b/c the min age has not
> expired.
>
> That should never happen, as I assume the password admin has a complete
> accesss to the policy and the passwords.
>
> Now, to be clear, the draft stipulates:
> "The access control that is used to determine whether an identity is a
> password administrator or password policy administrator is beyond the
> scope of this document"
>
> Which means there is no description on how the server detects that a
> user is a password admin.
>
>>
>> With admin roles, the administrator is subjected to a different pw
>> policy on the user’s entry. Presumably one that doesn’t have the min
>> age restriction.
>
> Are "admin roles" are equivalent to "Adminsistrative Roles" for you? In
> LDAP, Administrative Roles are a very specific thing. they define a
> specific DiT area on which applies a specific operation, like:
> - collective atributes (Which attribute should be added to en entry
> dependning on its position in teh DiT)
> - AccessControl (which kind of ACl applies to which part of teh DiT)
> - Schema (which schema applies to the defined DiT area)
>
> In the PasswordPolicy use case, the Administrative Role would simply
> cover the definition of the area that will be subject to the password
> policy, but it says nothiong about which user can leverage it.
Actually, the 'admin' user - whoever that is - would have an
PasswordPolicy AdministrativeRole identifying it as the user being able
to reset passwords.
So it would be more than just defining the area on which this 'admin'
user can act on, it will define it as this special user,; otherwise it
would be arbitrary.
We may need to add this new AdministrativeRole for that purpose, indeed.
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: PasswordPolicy review
Posted by Emmanuel Lécharny <el...@gmail.com>.
On 2022/10/04 15:06, Shawn McKinney wrote:
>
>
>> On Sep 30, 2022, at 3:48 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>
>>
>> On 2022/09/29 16:57, Shawn McKinney wrote:
>>>> On Sep 29, 2022, at 8:11 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>>
>>>>>> * 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.`
>>>>
>>>> I'm nut sure I get what you mean... I don't see a valid reason to do an admin reset when a user is created. Admin will create the user, and we may have a request for the user to change its password, but it may be unrelated to what you wrote. What is the min age has to do with the fact we don't implement administrativeRoles ?
>>>>
>>>> VCan you clarify?
>>> Let’s take an example pw policy:
>>> - name: default
>>> sn: 'default'
>>> cn: 'default'
>>> description: 'test ppolicy'
>>> pwdAttribute: userPassword
>>> pwdAllowUserChange: 'TRUE'
>>> pwdSafeModify: 'FALSE'
>>> pwdInHistory: 5
>>> pwdCheckQuality: 2
>>> pwdMinLength: 6
>>> pwdMinAge: 86400
>>> pwdExpireWarning: 2880
>>> pwdGraceAuthNLimit: 0
>>> pwdLockout: 'TRUE'
>>> pwdFailureCountInterval: 600
>>> pwdMustChange: 'FALSE'
>>> pwdLockoutDuration: 300
>>> pwdMaxFailure: 5
>>> pwdMaxAge: 94608000
>>> Which is set as the default for the directory.
>>> Here the minAge is set to 1 day. Next we create a user entry via some automatic mechanism.
>>
>> So here this is a creation. This does nit count as a modification (reminder: Password Change is a Password Modify Operation operation when the current user performs the Password Change)
>
> Actually, it happened recently in an OpenLDAP env on a newly created user. The minAge prevented admin reset.
Well, I suspect this was an implementation dependent issue.
>
>> For whatever reason the new user doesn’t know the password and requests a reset before 1 day has elapsed.
>>
>> The first modification should pass. The second won't.
>>
>>
>> So, the admin attempts a pw reset but can’t b/c the min age has not expired.
>>
>> That should never happen, as I assume the password admin has a complete accesss to the policy and the passwords.
>>
>> Now, to be clear, the draft stipulates:
>> "The access control that is used to determine whether an identity is a password administrator or password policy administrator is beyond the scope of this document"
>>
>> Which means there is no description on how the server detects that a user is a password admin.
>>
>>> With admin roles, the administrator is subjected to a different pw policy on the user’s entry. Presumably one that doesn’t have the min age restriction.
>>
>> Are "admin roles" are equivalent to "Adminsistrative Roles" for you? In LDAP, Administrative Roles are a very specific thing. they define a specific DiT area on which applies a specific operation, like:
>> - collective atributes (Which attribute should be added to en entry dependning on its position in teh DiT)
>> - AccessControl (which kind of ACl applies to which part of teh DiT)
>> - Schema (which schema applies to the defined DiT area)
>
> Used the incorrect term. OpenLDAP calls them ‘rules’. It allows users who have a matching attribute be subjected to a different policy.
Understood. Thez pwdPolicySubEntry attribute is used to point to the
policy that applies for this specific entry. This is probably what
OpenLDAP uses.
Administrative role is a different mechanism which allows the definition
of a set of entries in the DiT that are subject of a policy, without
having to update each entry: either the entry is part of the defined
administrative area, or not. It's convenient, but it requires some extra
work.
>
> This is part of their support for ppolicy10.
>
>
>>
>> In the PasswordPolicy use case, the Administrative Role would simply cover the definition of the area that will be subject to the password policy, but it says nothiong about which user can leverage it.
>>
>> This is a grey area, to be frank ;-)-
>
> Agreed
>
> —
> Shawn
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
> For additional commands, e-mail: dev-help@directory.apache.org
>
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: PasswordPolicy review
Posted by Shawn McKinney <sm...@apache.org>.
> On Sep 30, 2022, at 3:48 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>
> On 2022/09/29 16:57, Shawn McKinney wrote:
>>> On Sep 29, 2022, at 8:11 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>
>>>>> * 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.`
>>>
>>> I'm nut sure I get what you mean... I don't see a valid reason to do an admin reset when a user is created. Admin will create the user, and we may have a request for the user to change its password, but it may be unrelated to what you wrote. What is the min age has to do with the fact we don't implement administrativeRoles ?
>>>
>>> VCan you clarify?
>> Let’s take an example pw policy:
>> - name: default
>> sn: 'default'
>> cn: 'default'
>> description: 'test ppolicy'
>> pwdAttribute: userPassword
>> pwdAllowUserChange: 'TRUE'
>> pwdSafeModify: 'FALSE'
>> pwdInHistory: 5
>> pwdCheckQuality: 2
>> pwdMinLength: 6
>> pwdMinAge: 86400
>> pwdExpireWarning: 2880
>> pwdGraceAuthNLimit: 0
>> pwdLockout: 'TRUE'
>> pwdFailureCountInterval: 600
>> pwdMustChange: 'FALSE'
>> pwdLockoutDuration: 300
>> pwdMaxFailure: 5
>> pwdMaxAge: 94608000
>> Which is set as the default for the directory.
>> Here the minAge is set to 1 day. Next we create a user entry via some automatic mechanism.
>
> So here this is a creation. This does nit count as a modification (reminder: Password Change is a Password Modify Operation operation when the current user performs the Password Change)
Actually, it happened recently in an OpenLDAP env on a newly created user. The minAge prevented admin reset.
> For whatever reason the new user doesn’t know the password and requests a reset before 1 day has elapsed.
>
> The first modification should pass. The second won't.
>
>
> So, the admin attempts a pw reset but can’t b/c the min age has not expired.
>
> That should never happen, as I assume the password admin has a complete accesss to the policy and the passwords.
>
> Now, to be clear, the draft stipulates:
> "The access control that is used to determine whether an identity is a password administrator or password policy administrator is beyond the scope of this document"
>
> Which means there is no description on how the server detects that a user is a password admin.
>
>> With admin roles, the administrator is subjected to a different pw policy on the user’s entry. Presumably one that doesn’t have the min age restriction.
>
> Are "admin roles" are equivalent to "Adminsistrative Roles" for you? In LDAP, Administrative Roles are a very specific thing. they define a specific DiT area on which applies a specific operation, like:
> - collective atributes (Which attribute should be added to en entry dependning on its position in teh DiT)
> - AccessControl (which kind of ACl applies to which part of teh DiT)
> - Schema (which schema applies to the defined DiT area)
Used the incorrect term. OpenLDAP calls them ‘rules’. It allows users who have a matching attribute be subjected to a different policy.
This is part of their support for ppolicy10.
>
> In the PasswordPolicy use case, the Administrative Role would simply cover the definition of the area that will be subject to the password policy, but it says nothiong about which user can leverage it.
>
> This is a grey area, to be frank ;-)-
Agreed
—
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: PasswordPolicy review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Hi Shawn,
On 2022/09/29 16:57, Shawn McKinney wrote:
>
>
>> On Sep 29, 2022, at 8:11 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>
>>>> * 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.`
>>
>> I'm nut sure I get what you mean... I don't see a valid reason to do an admin reset when a user is created. Admin will create the user, and we may have a request for the user to change its password, but it may be unrelated to what you wrote. What is the min age has to do with the fact we don't implement administrativeRoles ?
>>
>> VCan you clarify?
>
> Let’s take an example pw policy:
>
> - name: default
> sn: 'default'
> cn: 'default'
> description: 'test ppolicy'
> pwdAttribute: userPassword
> pwdAllowUserChange: 'TRUE'
> pwdSafeModify: 'FALSE'
> pwdInHistory: 5
> pwdCheckQuality: 2
> pwdMinLength: 6
> pwdMinAge: 86400
> pwdExpireWarning: 2880
> pwdGraceAuthNLimit: 0
> pwdLockout: 'TRUE'
> pwdFailureCountInterval: 600
> pwdMustChange: 'FALSE'
> pwdLockoutDuration: 300
> pwdMaxFailure: 5
> pwdMaxAge: 94608000
>
> Which is set as the default for the directory.
>
> Here the minAge is set to 1 day. Next we create a user entry via some automatic mechanism.
So here this is a creation. This does nit count as a modification
(reminder: Password Change is a Password Modify Operation operation when
the current user performs the Password Change)
For whatever reason the new user doesn’t know the password and
requests a reset before 1 day has elapsed.
The first modification should pass. The second won't.
So, the admin attempts a pw reset but can’t b/c the min age has not
expired.
That should never happen, as I assume the password admin has a complete
accesss to the policy and the passwords.
Now, to be clear, the draft stipulates:
"The access control that is used to determine whether an identity is a
password administrator or password policy administrator is beyond the
scope of this document"
Which means there is no description on how the server detects that a
user is a password admin.
>
> With admin roles, the administrator is subjected to a different pw policy on the user’s entry. Presumably one that doesn’t have the min age restriction.
Are "admin roles" are equivalent to "Adminsistrative Roles" for you? In
LDAP, Administrative Roles are a very specific thing. they define a
specific DiT area on which applies a specific operation, like:
- collective atributes (Which attribute should be added to en entry
dependning on its position in teh DiT)
- AccessControl (which kind of ACl applies to which part of teh DiT)
- Schema (which schema applies to the defined DiT area)
In the PasswordPolicy use case, the Administrative Role would simply
cover the definition of the area that will be subject to the password
policy, but it says nothiong about which user can leverage it.
This is a grey area, to be frank ;-)-
>
> Hope this makes sense.
>
> —
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
> For additional commands, e-mail: dev-help@directory.apache.org
>
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: PasswordPolicy review
Posted by Shawn McKinney <sm...@apache.org>.
> On Sep 29, 2022, at 8:11 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>>> * 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.`
>
> I'm nut sure I get what you mean... I don't see a valid reason to do an admin reset when a user is created. Admin will create the user, and we may have a request for the user to change its password, but it may be unrelated to what you wrote. What is the min age has to do with the fact we don't implement administrativeRoles ?
>
> VCan you clarify?
Let’s take an example pw policy:
- name: default
sn: 'default'
cn: 'default'
description: 'test ppolicy'
pwdAttribute: userPassword
pwdAllowUserChange: 'TRUE'
pwdSafeModify: 'FALSE'
pwdInHistory: 5
pwdCheckQuality: 2
pwdMinLength: 6
pwdMinAge: 86400
pwdExpireWarning: 2880
pwdGraceAuthNLimit: 0
pwdLockout: 'TRUE'
pwdFailureCountInterval: 600
pwdMustChange: 'FALSE'
pwdLockoutDuration: 300
pwdMaxFailure: 5
pwdMaxAge: 94608000
Which is set as the default for the directory.
Here the minAge is set to 1 day. Next we create a user entry via some automatic mechanism. For whatever reason the new user doesn’t know the password and requests a reset before 1 day has elapsed. So, the admin attempts a pw reset but can’t b/c the min age has not expired.
With admin roles, the administrator is subjected to a different pw policy on the user’s entry. Presumably one that doesn’t have the min age restriction.
Hope this makes sense.
—
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: PasswordPolicy review
Posted by Emmanuel Lécharny <el...@gmail.com>.
On 2022/09/21 15:31, Shawn McKinney wrote:
>
>
>> On Sep 20, 2022, at 3:25 PM, Emmanuel Lécharny <el...@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 not a rename, it's defining the attribute which will contain the
password. It can be whatever the user wants. But again, it's of little
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.`
I'm nut sure I get what you mean... I don't see a valid reason to do an
admin reset when a user is created. Admin will create the user, and we
may have a request for the user to change its password, but it may be
unrelated to what you wrote. What is the min age has to do with the fact
we don't implement administrativeRoles ?
VCan you clarify?
Thanks !
>
> 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-unsubscribe@directory.apache.org
> For additional commands, e-mail: dev-help@directory.apache.org
>
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: PasswordPolicy review
Posted by Shawn McKinney <sm...@apache.org>.
> On Sep 20, 2022, at 3:25 PM, Emmanuel Lécharny <el...@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-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org