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

[Daniel Engovatov <dengovatov@crosslogix.com>]

Let me clarify a bit.  The way I see the indexing working:
Policy is analysed and, for example, rules requiring attribute "foo" to
match are present.
Rules are indexed by the value of "foo" required to match.
Rules are indexed by each attribute required to match - so, yes it is
expensive to have
rules requiring many different attributes - but there is no way around this
anyway.

If a request, with an attribute "foo" comes in - rules are looked up -
constant time per
each attribute.  It is known in advance that rules requiring "foo" are
needed, so if it is
not present, automatically, the whole table of rules indexed by "foo" are
getting Indeterminate 
result in match - in constant time, that's what happens.  What to do with
all this rules - 
that's a different thing, but as long as we MAY have missing attributes in
match (they are (non)received with a request), this can happen and it does
scale well.

So it does scale as long as it is an match that can be hashed.


-----Original Message-----
From: Polar Humenn [mailto:polar@syr.edu]
Sent: Sunday, October 20, 2002 7:52 PM
To: Daniel Engovatov
Cc: '''Anne.Anderson@Sun.com' ' '; ''XACML TC ' '
Subject: RE: [xacml] bags and targets. Forwarded message from Seth
Proctor .


On Sat, 19 Oct 2002, Daniel Engovatov wrote:

> >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.
>
> Absoutely not.  The time to look up "John" in a hash map is the same
whether
> "John" is present or not.  It is O(1) for any case when it can be reduced
to
> an equality operation and indexed in advance - is not it?

I think you mean, the time to look up subject-id "John" in the hash map is
the same as looking up whether the subject-id is present or not.

It's one thing to *have* a subject id with "John" and look up applicable
policies. Its an entirely different thing to NOT have a bunch of ????
attributes and find out if there are any policies that want it.

Let's say you have a FirstApplicable combining Algorithm on the the policy
set. The first Target wants a "subject-id" match to "John". The second
wants a "weight" attribute of "100lbs". If you have a request with a
"subject-id" of "John" and no "weight" attribute. What happens?
What happens if you have a "weight" attribute of "100lbs", but no
"subject-id" attribute? What happens.

I know it's a seemingly simple case, but now expand that with many
policies, many targets, and also consider the recursive nature of the
policy set composition.

You end up having to encode the logic of the combining algorithms into
your missing attribute discovery.  Also, think of the Subject section
which has complex logic for dealing with different subjects.  That
evaluation is of greater complexity of just looking up policies against
attributes you already have.

The Target should determine the applicability of the policy or rule, and
nothing else. The complex logic goes in the condition. Indeterminate is
an error condition, it should not be relied upon for policy decisions.
That is an abuse of the intent. Use the right logic, and determine the
proper effect.

-Polar