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?


Ok, thinking about it some more, I don't believe the problem is *that* obscure ...

Polar Humenn wrote:

> If you take the approach that all attributes have validity intervals, then
> they may have many validity intervals. Hmmm, how about the Cantor set?

... and definitely not a Cantor Set like problem ... which I take to be some 
attempt of humor by a (perverted) mathematician ... ;-)

> Furthermore, which "valid" and "invalid" attributes do you include in the
> Request? How old? How new? How long?
> 
> For instance, the Request Handler would have to have some special concept
> of time, and for what the PDP access decision is expeciting of
> access-time, so it can supply the right valid (or currently yet to be
> valid), attributes to supply.
> 
> Where do you draw the line?

The drawing of the line seems pretty straight forward:

We have our repository of all the attribute and authorization policy assertions, 
and each single one of them has a simple validity time interval associated with 
it, like notValidBefore-notValidAfter.

The request context is enriched with an access time interval: 
noAccessBefore-noAccessAfter.

The PDP handler will now divide the access control decision up in sub-intervals 
that are determined by the overlapping certificate intervals, where each 
sub-interval will include all the relevant certs that are valid within that time 
interval.

If all authorization decisions for all the sub-intervals yield Permit, then the 
overall decision for the access time interval yields permit. Otherwise... (you 
fill in the truth table...).

The real issues only seem to occur if you add policy specific time dependencies, 
which can make deterministic evaluation "difficult". To deal with the 
straightforward time intervals of certificate validity seems trivial.

(... and as long as the handful of applicable assertions doesn't approach 
infinity, the Cantor Set issue doesn't seem to come in play...)

So maybe the problem is not related to "simple" certificate validity time 
intervals, but only in the use of time in the policy rules, which is something 
that WSPL tries to deal with. In other words, if WSPL can show us or prescribe 
how to deal with time intervals in policy rules, we should be ok for assertions.

-Frank.



> On Mon, 15 Mar 2004, Frank Siebenlist wrote:
> 
> 
>>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_workgroup.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_workgroup.php.
> 

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