xacml — archive

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

From: Polar Humenn <[email protected]>
To: [email protected]
Date: Sat, 19 Oct 2002 16:37:00 -0000

MHonArc v2.5.2 -->

xacml message

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

From: Polar Humenn <[email protected]>
To: Daniel Engovatov <[email protected]>
Date: Sat, 19 Oct 2002 16:35:19 -0400 (EDT)

On Sat, 19 Oct 2002, Daniel Engovatov wrote:

> Not sure what exactly is being broken -  the evaluation performed is exactly
> the same - the only difference is the "automatic" type convertion function
> application for this very narrow and well defined case.

That's not what I am talking about.

I am talking about taking you match statements and evaluating the request
context against them.

If you have 100,000 policies all of which only 3 apply to a subject-id of
"john".

You can take the information in the request context, i.e. subject-id of
John, and find those three policies by indexing, of which now, you apply
the combining algorithm against their evaluations.

Now, if you didn't have a request context with a subject-id attribute?

You might get other policies that apply on some other criteria, but you
would be forced to throw an Indeterminate? How would you even find those
policies to begin with?

If you are allowed to have a single policy with a TARGET that says "if you
don't have an attribute of "subject-id" throw an Indeterminate". That
forces the PDP to evaluate each and every target, all 100,000 of them for
each request, to make sure that the attributes are there.

Remember, the combining algorithms do funky things with indeterminates,
like make them disappear, in favor of Deny or Permit, up the evaluation
chain. So you would indeed have to evaluate each and every target of every
policy for each request, all 100,000 of them!

That is not what Targeting is for. It is supposed to aid in simple
indexing and finding of applicable policies.
Hal wouldn't you agree?

Otherwise, we might as well just get rid of target alltogether and leave
everything into a condition.

Targeting allows you to place simple critera for discovering the
applicability of a policy, and nothing else. If an attribute is needed and
it is not there, that logic should reside in the <Condition>, which MUST
be evaluated once the policy/rule is considered applicable.

-Polar

> Matching (member-of "blah" <designator>)  and (string-equal "blah" <implicit
> string-one-and-only<designator> >)  is the same - you can compile and make
> sure the type safety is satisfied just as well.  It is only a syntax issue
> to allow easier use of designators/selector in target without opening up the
> syntax to a full blown <apply> tree.
>
> If you have your context precompiled and verified you index the target in
> just the same way - you just write it down in a little bit diferent manner..
>
> But I do agree that everything complicated sould go into condition - but we
> already have our target structure.
>
> Daniel;
>
>
>