Re: [xacml-dev] Re: [xacml-users] XACML 2.0: Attribute Resolution

[Oleg Gryb <oleg_gryb@yahoo.com>]

Hi Seth,

Thank you for commenting and see my answers below.
I've decided to spawn a
separate thread related to attribute resolution to
make it easier to read. I'll
probably do the same with "Multiple Subjects" thread
if this discussion
continues.

--- Seth Proctor <Seth.Proctor@sun.com> wrote:
> 
> 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. 

You wrote in the first message: 

>"How
> do you know what
> policies will apply to the request, which policies
> will be referenced
> as part of evaluation, and therefore which attribute
> values will be
> needed?"

It seems to me that you've made an assumption there
that as soon as the
policies are known all attributes become known as well
and I was trying to
argue with that statement by saying that "dynamic"
attributes will rather
depend on other parameters like resource type, subject
and/or action than on
policy itself. I got that impression when was building
a real authorization
solution for a real system where resource ID was the
only
parameter that I needed to get dynamic attributes from
a database. After
thinking more about that I realized that subjects can
be used as parameters for attribute resolution as
well: e.g. if you want to
implement traditional RBAC where roles for a subject
are fetched from a
database then you'll need to implement subject ->
attributes adapter. As I
wrote before I do not rule out a possibility that
policy ID and action can be
used as parameters too, but I don't believe that a
policy ID alone is always
sufficient to resolve all attributes.


>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.

I'm glad that we have an agreement on that, but I
still don't understand why
attribute resolution is a mandatory PDP's feature. My
major objective when I build an authorization solution
is to make sure that I
can switch from one vendor to another if necessary. If
I use a "pure" PDP 
then this objective can be achieved easily because I
use only "getDecision" method
without attribute resolution. How I resolve attributes
is my own business that
has nothing to do with PDP: I can use XSLTs or I can
write my own
"resolver". After short deliberation I've actually
chosen the latter because it
gives me more flexibility. If I want to replace my
current PDP down the
road, I can do it easily. If I'd used a PDP that does
attribute resolution I
would've inevitably been locked in in this particular
vendor/implementation.

> > 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

As I wrote before knowing "what policy is chosen"
might not give us sufficient
information for resolving all attributes and that the
statement that "we
need to know policy to resolve attribute" doesn't seem
to be correct in a
general case.If knowing policy is not be very relevant
to attribute
resolution then resolving attributes on PEP (or any
other place) does not seem
to be very different from resolving them on PDP.

> 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..

I agree with that too, but we have test II002 in
mandatory suite that requires
PDP to have attribute resoution mechanism. Does your
"there's
nothing wrong" comment mean that you would vote for
removing II002 from
mandatory tests?

> 
> seth
>