[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] request's attribute assertion lifetime?
Daniel Engovatov wrote: > Why should we treat time anyhow differently then any other attribute in > the context? Evaluation happens against the "snapshot" of the context > (or rather a fuzzy snapshot, as we do not regulate how that data will be > cached or provisioned). Time is just a dimension like any other. > > After the decision is made - it is PEP job on how and when to use it. Time is different than any other attribute as it moves in predictable ways. This is not a philosophical observation but is truly used. The PEP actually makes use of that property to note implicitly or explicitly that the current time is still within an acceptable range compared to the time for which the decision was evaluated. > For your example: > You are asking to evaluate not against a point in the context space, > with "current-time" fixed, but against an uncountable set in that space > (current-time from 4 to 6). I do not believe you can formulate such a > query in a generic way. Asking whether you can access at 4, and then at > 6 is not sufficient (you can be denied from 17:01 to 17:03) > > If you want to test what you can do from 4 to 6, introduce context > parameters "access-begin" "access-end" of type time, and write policy > making use of them. For example > GRANT(enter, building, joe) if access-begin < 2pm and access-end > 5pm. That is exactly what I was asking for when I said time interval. Except that I can not incorporate the validity time check for the assertions that are used in the evaluation as their validity is only compared to the current time before the PDP gets its hand on it. For what ever it worth, I haven't found any reference in the literature about access control policy expressions and evaluation that truly takes time intervals into account properly... I'm not sure what that implies... -Frank. > -----Original Message----- > From: Frank Siebenlist [mailto:franks@mcs.anl.gov] > Sent: Friday, March 05, 2004 3:57 PM > To: Polar Humenn > Cc: XACML TC > Subject: Re: [xacml] request's attribute assertion lifetime? > > In the scheduler use case that I sent out some time ago, this scheduler > has to > do mixing and matching of different scenarios where the access to > different > resources has to be aligned and lined up in time. > > How would we take care of such a use case where we want to test whether > some > subject is allowed to do such and such in the time interval from 4-6pm? > > Furthermore, with any statement that a pdp makes (or with any statement > that > anymone makes), there is timeliness associated. It is not realistic to > talk > about the the access control decision on the exact time T as the > enforcement > will never be on that same exact time T. In other words, we are already > fuzzy > about the implicit time-interval where the decision is believed to be > valid. > Maybe we should formalize that... (you of all people should like that > ;-) > > -Frank. > > > Polar Humenn wrote: > > >>On Thu, 4 Mar 2004, Frank Siebenlist wrote: >> >> >> >>>I understand all the arguments, except that if you want to run > > scenarios where > >>>you want to test the access control decision in some point in the > > future by > >>>playing with the environment's notion of time, you're unable to note > > the > >>>possible expiration of the attribute assertions... >> >> >>Either the attribute is there because it is "perceived" to be valid at >>time T, or it is not present. Say I want to test an access decision > > for > >>some time T in a year from now. If you have "attribute" certificates > > that > >>expire at time T-1, you shouldn't put those attributes in the request, > > as > >>they are not valid at time T. >> >> >> >>>Furthermore, if we move to a model where we will accept individual > > authorization > >>>assertions as policy statements, and with these assertion is a > > validity interval > >>>associated, then we won't be able to store them in the database ... >> >> >>Why not? I can store them in a database with as much meta data as I > > please > >>governing their validity. We do this with policies right now. There is > > no > >>argument at the PDP of whether a policy is valid or not. That is >>determined by a higher authority. >> >> >> >>>but will be forced to revalidate them before we feed them to the > > PDP/PAP > >>>every single time we use them. >> >> >>If you base your storage model that way, then you are completely > > correct. > >>Furthermore, there is a lot more to validation than just time. You may >>have to check the cryptographic signatures, the CRLs, various trust >>arguments, etc, all which should be kept out of the access decision. >> >> >> >>>It will also allow you to associate a upper-bound to the validity time > > interval > >>>of a decision. >> >> >>I don't agree that this is a needed capability. Either access is > > granted > >>at time T based on valid information for time T, or it isn't. > > Validity of > >>policy or policy elements is decided elsewhere. >> >> >> >>>Maybe we should make the checking of time validity a mandatory thing > > in the > >>>xacml engine, meaning that we optionally associate validity intervals > > with > >>>attribute and policy statements, and if they are present, >> >> >>I disagree. >> >> >> >>>they will always be checked with the evaluation time. >> >> >>There is no concept of "evaluation time". Time is merely an > > environmental > >>attribute. Hmmmm, what validity period does the time attribute have? >> >> >> >>>So, no need to write any policy rule tests for time validity as it > > will > >>>be done for you automatically and always. >> >> >>Time validity for a policy is governed by meta data about the policy, > > as > >>there are many different ways to accoplish this, it is nothing we > > should > >>standardize in XACML. >> >>We might form another TC to adress the problem, but lets not start >>throwing the worms in with the fish. >> >>Cheers, >>-Polar >> >> >> >>>-Frank. >>> >>> >>>Polar Humenn wrote: >>> >>> >>> >>>>On Thu, 4 Mar 2004, Frank Siebenlist wrote: >>>> >>>> >>>> >>>> >>>>>I just came accross the fact that the request's attribute element > > has an > >>>>>optional InstantIssue element to indicate the date and time at which > > the > >>>>>attribute was issued, but you can't seem to specify a duration > > validity interval. > >>>>>Any reason for that? >>>> >>>> >>>>All values attributed to resources, subjects, and actions pertinent > > to > >>>>the Access Decision Request should be validated for the request. > > (Another > >>>>reason why the PDP shouldn't supply the "current-time", a serious > > fault, > >>>>IMHO). The XACML Policy does not do validation. The PDP performs > > access > >>>>decisions based on valid information. >>>> >>>>The reason for this approach, is that we did not want XACML to become > > a > >>>>validation engine. The business of checking signatures, validity > > times, > >>>>handling cryptographic computational complexity, is all out of scope, > > and > >>>>that is easily divided and pawned off on some other entity, so XACML > > will > >>>>have to complicate is job with those matters. >>>> >>>>As far as Time goes, I never liked IssueInstant being in the >>>>ReqeustContext. Furthermore, you can't search on it using a >>>>AttributeDesignator, so it's existence is really moot, except, I > > guess, > >>>>for the XPath folks. >>>> >>>>Cheers, >>>>-Polar >>>> >>>> >>>> >>>> >>>> >>>>>Regards, Frank. >>>>> >>>>>-- >>>>>Frank Siebenlist franks@mcs.anl.gov >>>>>The Globus Alliance - Argonne National Laboratory >>>>> >>>>>To unsubscribe from this mailing list (and be removed from the > > roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgro > up.php. > >>>> >>>-- >>>Frank Siebenlist franks@mcs.anl.gov >>>The Globus Alliance - Argonne National Laboratory >>> >> >> > -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]