RE: [xacml] bags and targets. Forwarded message from Seth Proctor .

[Polar Humenn <polar@syr.edu>]

Anne,

Requiring an attribute to be there for a match in a target, requires you
to evaluate targets against your request context for your missing
attributes, which precludes doing easy target indexing on the request in
the first place.

The process of target indexing is actually the other way around. You have
a context with attributes, then you ask "Which policyies match these
attributes?".

You evaluate the request context against the targets.
You evaluate the conditions against the request context.

That functionality can be expressed in the condition with an appropriate
target that doesnn't match on your particular attribute.

But like I said, you shouldn't be writing policies based on
"Indeterminate". It is a bad error condition.

You should write expressions in the condition that yield the desired
effect for an access decision if such needed information is missing.

Cheers,
-Polar

On Fri, 18 Oct 2002, Anne Anderson wrote:

> On 18 October, Daniel Engovatov writes:
>  > What you are suggesting is that PDP should have some sort of an internal
>  > knowledge of what information must be available in the context and signal
>  > any discrepancy via Indeterminate result.  I do not think it is a workable
>  > operational requirement, especially given that we do not specify much about
>  > the internals of our virtual context (and I do not think we should).   Such
>  > intrusion detection is probably the job of the PIP service, and yes - it can
>  > pass Indeterminate value to the PDP if, for example, some SHA signature is
>  > off etc.   But that is not the job of the PDP, and an empty bag is a
>  > critically useful abstraction to use.
>
> I believe it is your interpretation that suggests that the PDP
> has some sort of internal knowledge about what information must
> be available in the context.  I am being very clear in saying
> that the PDP does NOT have that knowledge, and if it is unable to
> find an attribute that is referenced by an AttributeDesignator,
> for whatever reason, it will ALWAYS return "Indeterminate" as the
> result.
>
>  > If you want to write your policy in the way, that prohibits access if
>  > something is missing - you can.  Polar suggested several different
>  > approaches to this - using present, *-one-and-only will achieve the same
>  > effect.
>
> a) I can't use those in the Target
> b) If I try to use an attribute whose retrieval could fail in a
>    Target, then the Target will evaluate to NotApplicable.  This
>    will happen even if a temporary network glitch was the cause
>    for the attribute retrieval failure, and even if the policy
>    has a "Deny" effect and would have caused me to deny access
>    had the attribute been available.
>
>  > I do not remember whether we agreed or even discussed my proposal to treat
>  > designator supplied as an argument to a function requiring a single value
>  > attribute as an implicitly wrapped in *-one-and-only type transformation
>  > (but at least several examples used around do treat it that way).
>  > Explicitly stating such an assumption will probably answer your concern - it
>  > does produce Indeterminate on missing attribute, when applied to a function
>  > requiring a singleton..
>
> That would answer only one concern.  I agree, however, that if we
> accept your interpretation, we must spell this out.
>
> Anne
> --
> Anne H. Anderson             Email: Anne.Anderson@Sun.COM
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311     Tel: 781/442-0928
> Burlington, MA 01803-0902 USA  Fax: 781/442-1692
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>