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

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

I remember that we had some discussions about the need to limit the 
expressiveness of XACML in WSPL for reasons very similar to the ones you point out.

One observation of the delegation of rights processing was that you could 
potentially chain authorization decsions from issuer to subject, but that 
chaining general delegation-policy statements was to hard because of the same 
reasons you point out.

It seems that Tim's "visionary" WSPL may prove more valuably outside of its 
intended scope. (or maybe Tim was even more visionary than I give him credit for ;-)

-Frank.


Daniel Engovatov wrote:

> How would you deal with caching a decision from a policy
> Grant(something) (from 3 to 5) and (direction =  in)
> Deny(same thing) (from 4 to 4:30) and (last_name = engovatov)
> 
> Simple intersections will not cut it.   To deal with intervals properly
> you do need to express them as a data type.  To cache anything you need
> to trace ALL changes in the context, not just time.
> 
> I doubt it would be simple.   And you already can express all this rules
> using XACML and extensions to XACML - it just would not be easy to
> construct a query that answers your question.
> 
> Daniel.
> 
> 
> -----Original Message-----
> From: Frank Siebenlist [mailto:franks@mcs.anl.gov] 
> Sent: Monday, March 15, 2004 10:37 AM
> To: Anne.Anderson@Sun.COM
> Cc: Polar Humenn; XACML TC
> Subject: Re: [xacml] request's attribute assertion lifetime?
> 
> Ann just beat me to it ... while trying to make the equivalent point
> about 
> WSPL's capabilities, I checked my email one more time ... it must have
> something 
> to do with those great minds and such ;-)
> 
> The use case that I've brought up a number of times on different
> occasions is 
> that scheduler application that is running scenarios of service
> invocation 
> requests where it tries to match-up different resource availabilities.
> For these 
> scenarios, the authorization decision query is not about a single point
> in time, 
> but for a time interval: "Is the requester allowed to make use of the
> resource 
> from T1 till T2?".
> 
> Furthermore, as I tried to argue before, decisions for a single time T
> are not 
> very useful in practice and we rely on unspoken, implicit time-intervals
> for 
> which we assume the validity of that decision.
> This simplification works well if the time interval between decision and
> 
> enforcement are "small" (seconds-minutes) compared to the validity times
> 
> associated with the assertions used (days-months-years).
> 
> In our grid applications, we already work with
> identity/attribute/authorization 
> assertions that have lifetimes of hours. This will most certainly
> overlap with 
> the time intervals used for the scenario testing.
> 
> The other advantage is of course caching of authorization decision
> results. If 
> we have a good way to reason about the time validity of results as they
> relate 
> to the associated time validity of the assertions these results are
> based on, 
> then we might be able to reuse those decisions without having to go
> through a 
> potentially expensive reevaluation.
> 
> -Frank.
> 
> 
> Anne Anderson wrote:
> 
> 
>>WSPL also provides a way to tackle the problem of intervals.  Let
>>X be the attribute about which interval-type questions are
>>asked.  It might be a milepost on a road, a time of day, etc.
>>Assume the Resource Accessor's policy says "X >= 5 AND X <= 8".
>>
>>1) If the Resource Protector's policy says "X >= 2 AND X <= 9",
>>   then the merged policy says "X=> 5 AND X <= 8", indicating
>>   that the Resource Accessor's entire range is acceptable.
>>2) If the Resource Protector's policy says "X >= 6 AND X <= 9",
>>   then the merged policy says "X >= 6 AND X <= 8", indicating
>>   that only part of the Resource Accessor's desired range is
>>   acceptable.
>>3) If the Resource Protector's policy says "X >= 1 AND X <= 4",
>>   then the merged policy is empty, indicating the Resource
>>   Accessor's desired range is completely unacceptable.
>>
>>The Resource Accessor in the WSPL case doesn't get a simple
>>"Permit" or "Deny" answer, but perhaps this more complex result
>>is appropriate for the more complex concept of intervals.
>>
>>Anne
>>
>>On 15 March, Polar Humenn writes: Re: [xacml] request's attribute
> 
> assertion lifetime?
> 
>> > From: Polar Humenn <polar@syr.edu>
>> > To: Frank Siebenlist <franks@mcs.anl.gov>
>> > Cc: Daniel Engovatov <dengovatov@bea.com>, XACML TC
> 
> <xacml@lists.oasis-open.org>
> 
>> > Subject: Re: [xacml] request's attribute assertion lifetime?
>> > Date: Mon, 15 Mar 2004 10:28:44 -0500 (EST)
>> > 
>> > 
>> > Greetings,
>> > 
>> > Spring Break is over, I am back :)
>> > 
>> > On Wed, 10 Mar 2004, Frank Siebenlist wrote:
>> > 
>> > > [snip]
>> > 
>> > > Time is different than any other attribute as it moves in
> 
> predictable ways. This
> 
>> > > is not a philosophical observation but is truly used.
>> > 
>> > True, which is exactly why we shouldn't go diving into throwing XML
>> > attributes around to solve a complicated problem without major
> 
> study.
> 
>> > 
>> > XACML presently defines access control on attributes assumed to be
> 
> valid,
> 
>> > whether that validity is based on time, issuer, signatures, which
> 
> is all
> 
>> > up to the Request Handler. Admittedly, we do not have a
> 
> specification for
> 
>> > the Request Handler (of which I think Daniel would like).
>> > 
>> > I can forsee, however, some form of XACML to handle the problem of
>> > intervals, but if needed, as an extension, and only after
> 
> significant
> 
>> > research in the area. Please keep in mind that intervals not only
> 
> apply to
> 
>> > time. For instance, "Is Alice allowed on section of road R between
> 
> points
> 
>> > A and B?"
>> > 
>> > We may tackle this problem by forming a specific committee to study
> 
> the
> 
>> > issue for Intervals Based XACML or some such thingy. There is a lot
> 
> of
> 
>> > research in temporal logics and such that may be helpful. However,
> 
> I would
> 
>> > like to see a significant interest in the subject and commitment to
> 
> study
> 
>> > before we attempt to solve one small use case, which can be solved
> 
> by
> 
>> > formulating attributes in the way that Daniel described.
>> > 
>> > Cheers,
>> > -Polar
>> > 
>> > 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