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

[Polar Humenn <polar@syr.edu>]

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;
>
>
> -----Original Message-----
> From: Polar Humenn
> To: Daniel Engovatov
> Cc: 'Anne.Anderson@Sun.com'; XACML TC
> Sent: 10/19/02 12:43 PM
> Subject: RE: [xacml] bags and targets. Forwarded message from Seth Proctor .
>
>
> Even so, this appraoch breaks the whole ease of targeting policies.
>
> This requires that you need to evaluated all your targets for every
> request to make sure that you do not have an interdeterimate comming up
> from some error condtion of not not having a particular attribute.
>
> You want to take the information given to you in the request context and
> select the applicable policies. Write those policies as such. If you
> have
> special requirements such that an attribute must be present with some
> value, that is a "complicated" evaluation and should go in the
> condition.
>
> Otherwise, Policy Targeting is just another "hard" evaluation, and we
> might as well eliminate it all together.
>
> -Polar
>
>
> On Fri, 18 Oct 2002, Daniel Engovatov wrote:
>
> >
> > We probably should discuss my suggestion.  Implicit *-one-and-only
> type
> > transformation when selector/Designator is used as an argument that
> must be
> > of singleton type is safe, clear and answers your concerns about its
> use in
> > Target.  If you, indeed need one and only one argument (and any
> function
> > requiring a sigleton does, by definition) anything else will yield
> > Indeterminate (which is indeed a bad condition one should not rely
> upon for
> > expressing the policy logic - it is there since errors do happen in
> our
> > externalized data model and computation model and we needed a clear
> and
> > deterministic mechanism of dealing with them).
> >
> > Daniel.
> >
> > ---------------------------------------
> > 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>
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>