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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
