xacml — archive

[Erik Rissanen]

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