Open GoogleCodeExporter opened 9 years ago
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
Original comment by ppz...@gmail.com
on 29 May 2008 at 5:40
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
Original issue reported on code.google.com by
kenny.pe...@hxti.com
on 28 May 2008 at 7:27