[389-devel] Re: Please have look at One-Time Password password policy

> On 25 Mar 2021, at 12:00, Mark Reynolds <mreynolds@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@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