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?



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

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.



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