OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

> > To summarize: I think it's a good idea to get all
> > attributes resolved before request hits a PDP.
> The problem is that this is an impossible task. In
> all but the most
> closed and limited systems, it's a very hard task
> (in general) to know
> all attributes that will be useful for a given
> request. How do you know
> all attributes associated with the given user? 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?

I think, I know at least one person who can answer all
these questions: this person is a policy creator. If a
policy creator can't answer the qs about how (subject,
action, resource) vector (SAR) is mapped to attributes
that are required to do authorization job, then I
would not trust much to this policy creator or to her

If you agree with this statement than the next step
for policy creator is to feed that knowledge to PIP.
It doesn't matter how/by whom PIP is called in this
case: from PDP using a context handler or before PDP
is called.

I think that interoperability between different PDP
implementations is the most important feature that
must be addressed by the standard. There are two grey
areas  in XACML 2.0 that might make policy interop

1. Definition of context handler
2. Definition of references

How a policy that uses references can be interoperable
 if refernce resolution is vendor specific?

How policy that relies on missing attribute resolution
made by PDP can be interoperable if it's not even
clear from XACML 2.0 that such a mechanizm must exist.

Sun's implementation has the concept of plugin that
can be called from PDP and IBM's implementation
doesn't (attributes must be resolved before a request
hits their PDP). Still IBM states that they are XACML
2.0 compliant. What are you going to do about that?

I think XACML 2.0 should clearly define a core (or
mandatory) features that must be inteoperable between
different vendors and extensions that might be
vendor-specific. I think references and attribute
resolution should fall to the second category. A
policy creator must understand clearly that when an
extension is used the solution will not be

> seth
> To unsubscribe, e-mail:
> xacml-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail:
> xacml-dev-help@lists.oasis-open.org

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]