On 3/24/21 12:16 AM, William Brown wrote:
On 24 Mar 2021, at 02:12, thierry bordaz <tbor...@redhat.com> wrote:
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 maybe it could be easy to visualise it.
We have time going from past to future like:
past ---------------------------------------------------------> future
So we want a window of:
* When can the OTP start to be used?
* When is the OTP no longer able to be used?
So my thinking is:
past ---------------------------------------------------------> future
^ ^ ^
| | |
otp created | |
otp valid from |
otp expire at
So I would say otp valid from and the otp expire should be *absolute* date
times in UTC.
Hi William
Good idea of that graphic. I am sorry to be so slow to understand but
still things are not clear.
There are the attributes of the password policy and the operational
attribute of the user account.
I think you meant and I agree with you that operational attributes (in
the user account) should be absolute date.
What is not clear to me is how to compute those operational attributes
from the password policy.
I see three options:
1. password policy contains absolute time (e.g.
passwordOTPValidFromUTC) => account.validFrom = policyValidFromUTC
2. password policy contains a delay after OTP create/reset (e.g.
passwordOTPValidFromDelay) => account.validFrom = Now +
policyValidFromDelay
3. password policy contains both and if both are set we should give the
priority to one or the other
If a password policy is a stable entry, then they should not contain
absolute time. If we imagine password policy created on purpose to do a
bunch of registration, then that is okay if they contain absolute time.
Do you think we should support password policy with absolute time ?
thanks
thierry
And then within that otp valid from - expire at time window, we have the "max
use" field of how many times it can be used.
Does that help?
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.
Ahh I think I missed that this is using the userPassword and combined with
passwordPolicy. That makes sense now.
Still better to keep it consistent - all pwd or all password. I think you
mix/match these ....
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.
I'd see above :)
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'
Ignore this comment - I think I missed about the passwordPolicy bit :)
Hope that helps!
Absolutely it helps a lot. Thanks !
thierry
On 22 Mar 2021, at 21:30, thierry bordaz <tbor...@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
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@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
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@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure