On 10/29/2013 10:18 AM, Rob Crittenden wrote:
> 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.
>
We have time defined as:
-------------------------------------------------------------
Expressing Time in a Rule
There are several approaches that can be used to deal with time.
* One approach is to use binary blob to represent an array of access
time buckets
* Another is to have ranges.
We evaluated the two approaches and decided to go with the approach
based on ranges.
Time Attribute
The following attribute is used to store range information:
attributeTypes ( 2.16.840.1.113730.3.8.3.15
NAME 'accessTime'
DESC 'Access time'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'IPA v2' )
It is important to acknowledge that this is a multi-valued attribute and
that the same rule can have a number of range values. All of these
values are retrieved by the client and validated for each HBAC rule. If
no value is specified then the caller should assume that the rule always
applies.
Grammar
The following grammar describes the format used to express ranges:
timerange = Absolute / Periodic
Absolute = "absolute" WSP generalizedTime WSP "~" WSP generalizedTime
generalizedTime as defined in RFC 4517 section 3.3.13 but without time zone at
the end.
Periodic = "periodic" WSP Yearly / Monthly / Weekly / Daily
Yearly = "yearly" WSP Y-specifier WSP HHMM WSP "~" WSP HHMM
Monthly = "monthly" WSP M-specifier WSP HHMM WSP "~" WSP HHMM
Weekly = "weekly" WSP W-specifier WSP HHMM WSP "~" WSP HHMM
Daily = "daily" WSP HHMM WSP "~" WSP HHMM
Y-specifier = Y-month / Y-week / Y-day
Y-month = "month" WSP month-number WSP M-specifier
Y-week = "week" WSP week-of-the-year WSP W-specifier
Y-day = "day" WSP day-of-the-year
M-specifier = M-week / M-day
M-week = "week" WSP week-of-the-month WSP W-specifier
M-day = "day" WSP day-of-the-month
W-specifier = "day" WSP day-of-the-week
month-number = interval 1-12
week-of-the-year = interval 1-52
week-of-the-month = interval 1-6
day-of-the-month = interval 1-31
day-of-the-week = interval 1-7 (or Mon-Sun)
HH = "00" to "23"
MM = "00" to "59"
interval XX-YY = a comma-separated list of items from XX to YY, or
dash-separated ranges.
For example, (interval 1-31) 3-7,10,12,15,25-31 with no spaces inside.
This grammar allows the creation of a flexible set of time ranges that
include both absolute and periodic date ranges. The dates in the range
do not contain any time zone information. Periodic ranges are stored
without time zone information in the same format as specified in the UI
and the CLI, and are interpreted on the client as a time range in the
local machine's time. Absolute ranges do not specify the time zone
because absolute time ranges must be specified in UTC. The UI and CLI
must convert time stamps entered in local time format during management
operations into UTC format. Applications that access LDAP directly for
this data must be aware of the rules and assumptions described above.
Examples of Expressing Time Ranges
To express a time range that applies on Saturday and Sunday from 9AM to
1PM EST every second week of every month, local machine time:
periodic monthly week 2 day Sat,Sun 0900-1300
To express a time range that applies from midnight, 10th of October,
2008, until midday, 15th of October, 2008, in UTC:
absolute 20081010000000 ~ 20081015120000
--------------------------------------------
I am not sure it is best though. There were some thoughts to express it
some other more standard calendaring format that is used in scheduling
meetings or events like in Zimbra.
This needs to be investigated.
Here are some pointers:
http://stackoverflow.com/questions/8657183/looking-for-an-advanced-jquery-based-scheduler-widget
> 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
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
