> On 25 Mar 2021, at 12:00, Mark Reynolds <mreynolds@xxxxxxxxxx> wrote: > > > 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 Yep, this is exactly what I meant :) > > > 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 — 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
