[Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI

[Rob Crittenden]

Petr Vobornik wrote:
> On 10/04/2013 10:16 PM, Nathaniel McCallum wrote:
>> This patch supersedes my patch 0017 and requires patches 0020-0023. I
>> believe I have solved all of the outstanding issues from the review of
>> patch 0017, unless otherwise noted:
>>
>> 1. I'm not actually sure what the format of the date parameters is.
>> Could someone clarify this for me? Should I do something differently
>> here?
>
> I think that date parameter is not used anywhere. IMO it should be
> designed soon since it will be needed in other tickets [1], [2] as well.
>
> [1] https://fedorahosted.org/freeipa/ticket/547 [RFE] Implement iCal
> based time managment in HBAC
> [2] https://fedorahosted.org/freeipa/ticket/3127 [RFE] Time-Based
> Account Lockout Policies in IPA

FYI the original HBAC time class is still in 
ipalib/parameters.py::AccessTime. It is supposed to provide a 
generalized time-like API. Not saying it has to remain.

I can't remember how much previous conversations about date/time 
handling were in mailing lists vs shouting matches on the phone, but it 
is quite a hard problem in a distributed system like IPA, particularly 
for the UI.

Thar be dragons.

rob

>
>>
>> 2. In this new version of the patch, we are writing default values for
>> many of the token attributes. It would be nice to have some global
>> defaults for these default values, but this is not currently
>> implemented. I think this would make a clean secondary patch on top of
>> this current patch.
>>
>> 3. Dmitri brought up the idea of having tokens automatically expire by
>> default. Is this a good idea? I think this dovetails nicely with #2
>> above.
>>
>> 4. This patch does not currently protect the deletion of the last token
>> as previously discussed. Here is why I think this is still needed, but
>> in the form of a DS plugin:
>>
>> We need to account for a state when the user is enabled for OTP but has
>> not yet configured any tokens. I believe this state should be when the
>> "otp" user auth type is set, but the user has no assigned tokens. In
>> this state, the user should be able to log in with single factor
>> authentication.
>>
>> Once the user has added tokens, however, should we allow the user to
>> remove all his own tokens and return to single factor authentication? If
>> yes, nothing further is needed. If no, then protection in the FreeIPA
>> framework is not sufficient and this needs to be checked at the DS
>> plugin level. I suspect Dmitri might answer that this needs to be a
>> matter of policy.
>>
>> 5. There appears to be some sort of permissions issue with users and
>> adding their own tokens. I have not looked into this yet, but I will
>> review this early next week. Since this is a small bug fix to an
>> existing feature, I figured it was out of scope for this patch.
>>
>> 6. When a user is deleted, all his tokens are deleted as well. This is
>> sensible default behavior. However, in the case of hardware tokens, it
>> may be more desirable to orphan these objects for future assignment to
>> new users. Does anyone have any opinions on this topic?
>>
>> Nathaniel
>>
>
>