RE: [xacml] A different approach to issue 66

["Hal Lockhart" <hal.lockhart@oracle.com>]

I thought we could do this with WS-XACML.  It many need some more explicit conventions, but the ability to specify vocabularies is already there.

The missing Attributes approach always was sort of crude. Only useful for certain use cases, such as reauthentication with a stronger method.

Hal

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Tuesday, September 30, 2008 10:26 AM
> To: XACML TC
> Subject: [xacml] 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
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>