indexing not supported with AttributeRetrievers

[GoogleCodeExporter]

Policy indexing doesn't appear to work with AttributeRetrievers.
(PolicyCache line 199.) There's not any reason why this shouldn't be able
to be supported is there? If you knew which attributes you needed, you
could retrieve them all before going looking for matching policy targets.

Original issue reported on code.google.com by kenny.pe...@hxti.com on 28 May 2008 at 7:27

[GoogleCodeExporter]

Its a good question.

The indexing mechanism is intent to reduce the policy search scope while a 
request is
coming. It eliminates those policies that obviously don't match the coming 
request.
It indexed policies using policy's required attributes, and retrieve policies 
using
the coming request's attributes.

For example, if a policy requires 2 attributes in its target, "attr1" and 
"attr2",
but the coming request only ships "attr3", obviously, this policy is not 
necessary to
be evaluated for the request, because it surely returns NotApplicable result 
for the
request. If the request ships "attr2" only, the policy will be retrieved and
evaluated against the request even the policy requires another attribute.

Ok, back to current issue. Considering above policy which requires "attr1" and
"attr2" attributes. If there is an AttributeRetriever in system supports all of 
these
2 attributes, regardless the coming request ships those attributes or not, this
policy should be evaluated against the request anyway, because it can get those
attributes from AttributeRetriever. Also, this policy should be evaluated 
against any
request since it doesn't require attributes from request, it can get them from
AttributeRetriever.  If we add this policy to the cache use attribute keys, it 
will
never be retrieved by request that doesn't ship the corresponding attributes.

That is to say, if an attribute is supported by AttributeRetriever, we should 
not
require the coming request to have this attribute. So we will treat above 
policy as
if it has an empty target, and it will be added to a common area 
(PolicyCache:61).

I tried to explain my design, please let me know if you still confuse.

-ppzian

Original comment by ppz...@gmail.com on 29 May 2008 at 5:09

• Changed state: Accepted
• Added labels: Type-Question
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by ppz...@gmail.com on 29 May 2008 at 5:40

[GoogleCodeExporter]

To make sure I understand: the indexing mechanism is based only on whether an
attribute exists, and if an attribute resolver knows how to resolve it it is 
assumed
always to exist?

I understand the difficulty of designing this sort of mechanism. I was thinking 
you
had come up with some "binary search tree"-like system for quickly finding 
applicable
policies based on attribute matching, but I really don't have a clear idea in 
my head
of how this could be done. Here's something that I think could be done, though: 
there
are a couple of attributes (e.g. 'role') that I have a whole bunch of policies 
to
match on. If the PDP could detect that situation (that more than a certain 
number of
policies match the same attribute), then it could construct a BST for each such
attribute and begin policy matching by traversing the tree for the one that 
matches
and throwing away the rest of the policies in the tree.

So, for example, I have the role "super-user". There are five policies that 
match
roles, and five policies that don't. The role policies get arranged into a BST 
based
on alphanumeric ordering of role names. The PDP gets my request and retrieves my
role, then traverses the tree to find the policy (or policies) in the tree that 
match
my role. It throws away the other four, and evaluates the one matching role 
policy
and the five non-role policies.

Just an idea.

Original comment by kenny.pe...@hxti.com on 29 May 2008 at 1:45