On 3/24/21 8:32 PM, William Brown wrote:
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:
• password policy contains absolute time (e.g. passwordOTPValidFromUTC) => account.validFrom = policyValidFromUTC
• password policy contains a delay after OTP create/reset (e.g. passwordOTPValidFromDelay) => account.validFrom = Now + policyValidFromDelay
• 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 ?
No we should not store actual times in the config. These time values need to live in the entry itself, just like passwordExpirationtime. Perhaps this is a good candidate to handle through the CLI (maybe even a new task that uses a filter, base, etc)?
I'm a bit confused about this answer but:
Theirry thought you wanted to set:
dn: cn=config
passwordOTPStartTime: 2021034578489754Z
But I was saying it should be in the entry, not cn=config, like how we
use passwordExpirationtime:
uid=mark,dc=example,dc=com
passwordOTPStartTime: 2021034578489754Z
Mark
I think there are no "operational" attributes here. These should all be absolute dates, set on the entry. No calculation or whatever needed.
There is no policy at all. Basicly you just have a mechanic that sets on the account that this password is only valid in these time windows, and can only be used a maximum number of times.
Mark
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
--
389 Directory Server Development Team
_______________________________________________
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
