OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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_workgroup.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]