<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 10/29/2013 10:18 AM, Rob Crittenden wrote: <blockquote cite="mid:526FC3B5.1010009@redhat.com" type="cite">Petr Vobornik wrote: <blockquote type="cite">On 10/04/2013 10:16 PM, Nathaniel McCallum wrote: <blockquote type="cite">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? </blockquote> 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] <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/547">https://fedorahosted.org/freeipa/ticket/547</a> [RFE] Implement iCal based time managment in HBAC [2] <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/3127">https://fedorahosted.org/freeipa/ticket/3127</a> [RFE] Time-Based Account Lockout Policies in IPA </blockquote> 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. </blockquote> We have time defined as: ------------------------------------------------------------- <h4> Expressing Time in a Rule </h4> There are several approaches that can be used to deal with time. <ul> <li> One approach is to use binary blob to represent an array of access time buckets </li> <li> Another is to have ranges. </li> </ul> We evaluated the two approaches and decided to go with the approach based on ranges. <h5> Time Attribute </h5> The following attribute is used to store range information: <pre> 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' ) </pre> 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. <h5> Grammar </h5> The following grammar describes the format used to express ranges: <pre>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. </pre> 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: <pre> periodic monthly week 2 day Sat,Sun 0900-1300 </pre> To express a time range that applies from midnight, 10th of October, 2008, until midday, 15th of October, 2008, in UTC: <pre> absolute 20081010000000 ~ 20081015120000 </pre> -------------------------------------------- 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: <a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/8657183/looking-for-an-advanced-jquery-based-scheduler-widget">http://stackoverflow.com/questions/8657183/looking-for-an-advanced-jquery-based-scheduler-widget</a> <blockquote cite="mid:526FC3B5.1010009@redhat.com" type="cite">rob <blockquote type="cite"> <blockquote type="cite"> 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 </blockquote> </blockquote> _______________________________________________ Freeipa-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-devel@redhat.com">Freeipa-devel@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a> </blockquote> <pre class="moz-signature" cols="72">-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? <a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a> </pre> </body> </html>