Re: [xacml-dev] Re: [xacml-users] XACML 2.0 Conformance Tests Questions

[Seth Proctor <Seth.Proctor@sun.com>]

Hi Oleg.
 
> Well, I think you should agree with a simple truth
> that there is no a universal mechanism to resolve an
> attribute. Moreover, I don't believe that there is an
> efficient way of binding a policy/policy set id to a
> set of relevant "dynamic" attributes (I think this is
> what Seth suggested). So the attribute mapping
> function is f(Subject,Resource,Attribute)->Attributes
> rather than f(Policy_ID) -> Attributes.

I'm not sure what you mean by this binding, but I don't think that I
suggested any kind of binding between policies and dynamically resolved
attribute values. I agree that there's no universal attribute resolution
approach, which is (to my mind) exactly why we're having this discussion.
Different systems want or need to fetch attribute values in very
different ways. Some can and indeed do supply all values up-front,
whereas others *need* to wait until certain points in the evaluation
of a policy before values are referenced. It is precisely because we
want to support this flexibility that we have a flexible model.
 
> It doesn't matter how many policy creators worked on a
> policy/policy set. They are still the single source of
> knowledge about what attributes they need and where
> these attributes are stored. They will need to
> communicate this knowledge to engineers who will
> create adapters to get attributes from different
> repositories. I still don't see a necessity to call
> attribute resolution logic from inside of PDP. If
> attribute model is changed, the adapters will need to
> reflect the change, no matter where the adapter is
> called from (from inside PDP or outside of PDP).

I think you've missed a step here. Yes, the author of a policy knows
what attributes might be needed by that policy, and can theoretically
publish this list. Given a published list, it's even possible to look
at policy references, and see what values a given tree of policies may
need to do a complete evaluation.

This said, how does the PEP know what policy will be chosen for a given
Request? This is supposed to be something that only the PDP knows, for
a variety of (in my opinion) good reasons. Actually, given how references
work, this is something that even the PDP may not know until evaluation
is already underway. So, even if a policy author knows what attributes
might be needed, that doesn't mean that the PEP knows which policy or
policies will be chosen for a given request, and therefore which values
will be required.

Given a very small set of policies, or a very small set of possible
attribute values used by the policies, a PDP could tell the PEP the
exhaustive possible set of attributes that might be needed. Of course,
this would typically result in much larger and more complex Requests
than are usually needed, more work ahead of time to gather values for
the Request, etc. It also raises privacy concerns, because many systems
don't want attributes to be presented unless they're actually needed
(sometimes this gets very interesting and tricky, involving negotiation).

Even given all of this, of course, it's perfectly valid to create a
new policy dynamically as part of evaluation. For instance, many people
have PDPs that handle the "more than one applicable top-level policy"
issue by dynamically creating a single parent PolicySet with a chosen
combining algorithm. You can also have a Policy Reference that doesn't
point to a physically existing policy, but one that is generated
dynamically based on some context (yes, I've seen this done many times).
Again, you could list out the possible attributes needed, but this gets
back to the same problems as above.

The bottom line is that there are many very good reasons for why the
model that XACML is based on (not invented by the XACML TC, but by others
who have been doing this for a long time) allows for an abstract context
where values can be fetched at run-time as needed. But if you don't
need this in a given system, or would rather just make sure that all
values are included in the Request, then there's nothing wrong with that
either. The model is flexible by design, and allows you to support as
little or as much as you'd like vis a vis attribute retrieval. There is
nothing wrong with having a PDP that can only use values from a physical
XACML Request document if that works for your environment..


seth