Re: [xacml] A different approach to issue 66

[Erik Rissanen <erik@axiomatics.com>]

Hal, All,

I had a look and WS-XACML does not do this already.

WS-XACML specifies WS-Policy assertions with fragments of XACML which 
can be used to express capabilities and requirements of web services and 
clients. It's not about requirements and capabilities of an XACML PDP 
itself.

There is a possibility to define which attribute vocabulary these 
fragments make use of in the form of vocabulary references. Matching of 
vocabularies is done by means of equality of the vocabulary identifier. 
This is not sufficient for Rich's use case.

Rich's use case was that there is a potentially large set of attributes 
supported by the PEP, but only a small subset of these attributes are 
actually used in a PDP. Ideally the PEP should only send this subset. 
What we need is a method to make fine grained matching of vocabularies 
defined in terms of sets of XACML attribute identifiers.

I was thinking about something like this:

Consider a PDP which has two policies, one about printing and another 
about the personnel roster.

<xacml:Policy>
  <Description>The policy about printing</Description>

  ...
  This policy makes use of the following subject attributes:

  http://example.com/attributes#role

  the following resource attributes:

  http://example.com/attributes#resource-type
  http://example.com/attributes#resource-physical-location

</xacml:Policy>


<xacml:Policy>
  <Description>The policy about the roster</Description>

  ...
  This policy makes use of the following subject attributes:

  http://example.com/attributes#role

  the following resource content schema (qname):

  {http://example.com/schema/roster}Roster

</xacml:Policy>

Define a XACML attribute assertion for WS-Policy called 
<ConsumedXACMLAttributes>:

Now, it would be possible for the PDP to publish the following WS-Policy 
to enable a PEP to work out which attributes it should send:

<wsp:Policy>
  <wsp:All>
    <wsp:ExactlyOne>
      <ConsumedXACMLAttributes>
        <Attribute AttributeId="http://example.com/attributes#role"; 
DataType="..."/>
      </ConsumedXACMLAttributes>
    </wsp:ExactlyOne>
    <wsp:ExactlyOne>
      <ConsumedXACMLAttributes>
        <Attribute 
AttributeId="http://example.com/attributes#resource-type"; DataType="..."/>
        <Attribute 
AttributeId="http://example.com/attributes#resource-physical-location"; 
DataType="..."/>
      </ConsumedXACMLAttributes>
      <ConsumedXACMLAttributes>
        <ContentElement namespace="http://example.com/schema/roster"; 
localname="Roster"/>
      </ConsumedXACMLAttributes>
    </wsp:ExactlyOne>
  </wsp:All>
</wsp:Policy>

(Not sure if the way I made <ContentElement> is the prettiest possible 
solution.)

Let's say that the printer PEP is capable of producing the following 
attributes:

  http://example.com/attributes#resource-type
  http://example.com/attributes#resource-physical-location
  http://example.com/attributes#color-capable
  http://example.com/attributes#printer-remaining-paper

In this case the printer PEP would now that it needs to send the 
resource type and the physical location attributes in the request, and 
it would also know that it can skip sending the color-capable and 
remaining paper attributes since the policies won't make use of those 
attribute.

The roster PEP can instead send the roster in the form of an XML document.

Both PEPs would know that they need to send the subject role.

I think a solution like this captures Rich's use case much better than 
the MissingAttributesDetail.

Naturally, this is just a sketch for an idea and I am even not sure what 
the open issues are. But I think the basic approach should be workable. 
And in most cases I think the WS-Policies could be automatically derived 
from the XACML policies (except perhaps for the <Content> part, where 
interpreting xpaths could be difficult).

So I propose that:

- We fix the MissingAttributesDetail in the XACML 3.0 core spec so it 
includes the category of the missing attribute, since otherwise it is 
ambiguous.

- We defer the full solution of the problem into a separate profile for 
WS-Policy (or similar) based attribute publishing policies.

Possibly we could define some behavior for which MissingAttributeDetails 
the PDP should produce, but I cannot think of any meaningful behavior. 
For instance, in the above examples, when the roster PEP calls the PDP, 
but there is not a permit decision, should the PDP report the 
resource-type and physical location attributes as missing? If not, how 
can the PDP tell that?

Regards,
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
>>
>>     
>
>