Wednesday, March 24, 2021

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

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@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

No comments:

Post a Comment