Hi William
Thanks for you review. Some answers are inlined in the mail below.
On 3/23/21 12:33 AM, William Brown wrote:
Hey there,
I think that you also need:
pwdOTPValidFromTime
This way an admin can pre-configure all the OTP's and they only "become valid from" that time frame. IE think university enrollment. You can configure all the OTP's a month before, and they become valid at a specific datetime.
That is a very nice idea. Note to be OTP the 'userpassword' of the
account must be reset by an admin and the account inheriting password
policy with OTP settings.
Assuming 'pwdOTPValidFromTime' is the account operational attribute
holding a precise time. How should it be computed ? Directly from a
precise time set in the password policy or computed from a '
'passwordOTPValidationDelay' (number of seconds after OTP reset time) or
something else ?
I think you should make it consistent with passwordOTPExpDelay to pwdOTPExpDelay. Better, OTP means "one time password" so why is it "password one time password". Just make the attributes "OTPExpDelay" or whatever. Alternately make it pwdOT (password one time).
ATM password policy ('passwordPolicy') only contains 'password*'
attributes this is why I would prefer to keep 'passwordOTP*' (e.g.
passwordOTPMaxUse, passwordOTPExpirationDelay, passwordOTPValidFromTime').
I agree that 'passwordOTP' looks weird ("password one time password")
but the first 'password' is the way the password policy attribute are
prefixed.
Then the account operational attributes updated via password policy.
There is a mix.
6 out of 10 start with 'password' (like 'passwordExpirationTime')
2 out of 10 start with 'pwd' (like 'pwdReset')
The two remaining are 'retryCountResetTime' and 'accountUnlockTime'.
I choose the 'pwdOTP' prefix because the feature is somehow related to
'pwdReset' and also I preferred a different prefix than the password policy.
I think passwordOTPExpDelay can be remove if you have ValidFromTime instead.
Why ? Registration should be done after Now+ValidFromTime and before
Now+passwordOTPExpDelay.
So the two are useful.
The OC should be named onetimepasswordPolicy instead.
Do you suggest we have two password policies OC: passwordPolicy and
OnTimePasswordPolicy.
OTP relying on 'passwordMustChange' then OnTimePasswordPolicy should
allow 'passwordMustChange'
Hope that helps!
Absolutely it helps a lot. Thanks !
thierry
On 22 Mar 2021, at 21:30, thierry bordaz <tbordaz@xxxxxxxxxx> wrote:
Hi,
I wrote a small design [1] about OTP password policy that I would like to start implementing.
Comments are welcome
[1] https://www.port389.org/docs/389ds/design/otp-password-policy.html
best regards
thierry
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
