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?


Why all this intricate, convoluted way of adding completely unneeded
information into the context (Not all policies care about time)
When the problem is (almost trivially) solved by a combination of
existing solutions:

1) Context handler will return INTEDERMINATE for a certificate that is
invalid for any reason (time is only one, quite narrow, dimension)
2) Any interval evaluations can be handled either with explicit
operations, or by introducing a range data type.
3) If one want an explicit policy for time validity: you can use a
separate policy, invoked by the context handler to check this validity,
or introduce all the attribute metadata as part of the context.

In general, sources of context data do NOT have such metadata attached
to it.  In general, they may have zillion of other criteria to determine
validity of a data piece: signatures for example.

We do have an explicit, well defined way of dealing with bad data - the
INDETERMINATE value.

Because, many systems will not have this metadata available, it will
need to be an optional feature.  Why would we add optional features for
functionality that can be solved using existing ones?

I think we should maintain a clear separation of handling data and
handling parametric policy.  PDP is not a good place to deal with
certificates.

And you still did not show how you would deal with other time dependent
rules.

For example

GRANT(swim) if 3pm < time < 5pm  AND tide < 1ft.

What is the "isValid" interval for this policy?

Daniel.


-----Original Message-----
From: Frank Siebenlist [mailto:franks@mcs.anl.gov] 
Sent: Monday, March 15, 2004 1:54 PM
To: Polar Humenn
Cc: Anne.Anderson@Sun.COM; XACML TC
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_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.
> 

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