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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: A different approach to issue 66


All,

I have given some thought to issue 66, and I think a different approach 
is needed.

This issue concerns coordinating the attribute vocabularies of a PEP and 
policies in a PDP.

Currently the discussion has been about using the "missing attributes" 
in the XACML response, but I think this is the wrong approach:

1. "Missing attributes" are not sufficiently expressive to be able to 
solve this problem, since the PDP might contain multiple policy "topics" 
which each require different attribute vocabularies. Missing attributes 
would mix up them and it would be hard to make use of the result on the 
PEP side.

2. "Missing attributes" are inefficient since it means evaluating 
policies and restarting evaluation again, which could go a different 
path in the next round, leading to still more missing attributes. There 
are no good bounds on how many rounds are needed until the process 
terminates.

3. "Missing attributes" are bad architecture since it mixes two 
fundamentally different problems: attribute coordination and policy 
evaluation. This makes it harder to make independent changes in these 
two issues in the future.

I have another proposal instead. These are just some early thoughts, but 
I am posting them anyway to get the discussion started early.

I suggest we can use WS-Policy for attribute negotiation. We would need 
to define some attribute producer and attribute consumer assertions.

A PEP could publish a WS-Policy which states that it is capable of 
producing some specific XACML attributes.

A PDP could publish a WS-Policy which states that it requires a 
particular XACML attribute vocabulary. This WS-Policy could use the 
WS-Policy structure to express alternative attribute vocabularies if 
there are different XACML policy "topics". For instance, a single PDP 
might contain XACML policies of both printers and email accounts. These 
two "topics" would make use of different attributes and these two 
attibute vocabularies would be published as different alternatives in 
the PDP attribute requirement policy. The PEP for printers would see 
that it can meet the requirements of the printer vocabulary, while the 
email PEP would make use of the other alternative.

I have not worked on any more details, and I have not yet verified that 
this idea would actually work. But if it works, it would have the 
following benefits:

1. Expressive enought to be able to express full vocabularies in a 
single round of negotiation, so it is more efficient than missing 
attributes.

2. Does not interfere with XACML policy evaluation schemas or 
functionality, thus splitting up the architecture more cleanly, and any 
runtime overhead is separated into a separate protocol exchange, and 
would not affect each and every XACML response.

3. The attribute WS-Policy published by the PEP can be used by policy 
editing tools to help XACML policy authoring.

4. The attribute WS-Policy published by the PDP can be used to minimize 
the set of attributes sent by the PEP in each request.

Some open issues:

How is the PDP side attribute WS-Policy constructed? Ideally it would be 
derived from the XACML policies. At least two possibilities occurs to 
me. A: Extract the attributes which XACML policies refer via attribute 
designators or selectors (selector requirements could be represented as 
XML schema namespaces and elements in the WS-Policy). B: Make 
management/construction of the attribute WS-Policy part of the XACML 
editor, so the XACML policy author can define the vocabulary at the same 
time he defines the XACML policies.

Best regards,
Erik




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