Re: [xacml] request's attribute assertion lifetime?

[Frank Siebenlist <franks@mcs.anl.gov>]

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

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 but will be 
forced to revalidate them before we feed them to the PDP/PAP every single time 
we use them.

It will also allow you to associate a upper-bound to the validity time interval 
of a decision.

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, they will always be 
checked with the evaluation time. So, no need to write any policy rule tests for 
time validity as it will be done for you automatically and always.

-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