Re: [xacml] A different approach to issue 66

[Erik Rissanen <erik@axiomatics.com>]

It was a while since I read the WS-XACML draft, but what you say rings a 
bell. If it's already there, that's even better. :-)

/Erik

Hal Lockhart wrote:
> 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
>>
>>     
>
>