Re: [xacml] Issues 63, 71 and 77

[Anne Anderson - Sun Microsystems <Anne.Anderson@sun.com>]

I agree with all Erik's proposals, with one proposed modification to 
#63.  My comments are in-line below.  -Anne

Erik Rissanen wrote:
...
> For issue 63 there is a proposed solution on the Wiki. I propose that we
> adopt it.

Agreed.  See note below at the bottom of the page.

> It also solves issue 77. We simply drop the resource-id xml attribute
> from the response and use the includeInResult xml attribute and return
> full XACML attributes, which can be any datatype.

Agreed.

> During the discussion of this solution Hal raised issue 71, "Treating
> different subject categories as different entities". Do we want this in
> 3.0? I am not keen on it. It would require quite a bit of changes in the
> schema and the specification text and the use cases are not clear to me.
> For instance, new functions which can match multiple categories need to
> be defined, the the behavior of the current Designators need to be
> clarified in the context of multiple categories and some other way to do
> multiple resources need to be devised.

The best use cases I've seen involve policies based on the contents of 
XML documents, where the policy places conditions on more than one 
repeated element.  For example, given the following credit report:

      <CreditReport>
         <Name>Anne Anderson</Name>
         <Account>
            <Creditor>Bank1</Creditor>
            <Type>Mortgage Loan</Type>
            <Balance>50000</Balance>
            <LatePaymentsLast12Months>0</LatePaymentsLast12Months>
         </Account>
         <Account>
            <Creditor>Visa</Creditor>
            <Type>CreditCard</Type>
            <Balance>100</Balance>
            <LatePaymentsLast12Months>4</LatePaymentsLast12Months>
         </Account>
      </CreditReport>

the policy may want to deny access to a Subject whose credit report 
shows any single account where the balance is > $1000 and the number of 
late payments in the past year is > 3.

Nevertheless, I agree we should not try to do this, because it requires 
a different, more complex language model.  Want to try to explain lambda 
expressions to the average policy administrator :-) ?

Note that it is possible to place a single restriction across all 
instances of a repeated node using the bag functions and higher-order 
functions.  For example, given the credit report above, the following is 
a test that will return "true" if "any <LatePaymentsLast12Months> value 
is greater than 3"

     <Apply FunctionId="...:any-of">
        <Function FunctionId="...:integer-less-than">
        <AttributeValue DataType="...#integer">3</AttributeValue>
        <AttributeSelector 
RequestContextPath="//CreditReport/Account/LatePaymentsLast12Months/text()"
DataType="...#integer"/>
     </Apply>

> Hal, do you have a proposal to do it? There is the MultipleCondition
> (which was part of delegation for a while) and the function which Anne
> presented at the F2F which you could start from.
> 
> Here is a copy of the proposed solution for issue 63 your convenience:
> 
> ---8<---
> Simplified, the multiple resources profile allows multiple Resource
> elements in a request. These are then interpreted as if there were
> multiple requests, which are evaluated individually. The Reponse will
> contain multiple Results.
> 
> With generalization of attribute categories, the resource category is
> not special anymore, so the multiple resources profile is broken. We
> could solve that by making the resource category special, or by
> generalizing the profile. I suggest that we generalize. Here is how we
> could do so.
> 
> The first issue is the resource-id which is part of a Response. 
...
> 
> The second issue is to know which category is the “Resource”. I suggest
> that one category can be repeated in the Attributes elements. The
> meaning of this is that the PDP should run multiple requests, where each
> repeated Attributes category is present only once and the rest of them
> are the same for all requests. Like this:
> 
> <Request>
>   <Attributes Category=”MyNiftyCategory”>
>     <Attribute AttributeId=”myIdAttr” includeInResult=”true”>
>       <AttributeValue>12345</AttributeValue>
>     </Attribute>
>   <Attributes>
>   <Attributes Category=”MyNiftyCategory”>
>     <Attribute AttributeId=”myIdAttr” includeInResult=”true”>
>       <AttributeValue>ABC</AttributeValue>
>     </Attribute>
>   <Attributes>
>   <Attributes Category=”AnotherCategory”>
>     <Attribute AttributeId=”color”>
>       <AttributeValue>red</AttributeValue>
>     </Attribute>
>   <Attributes>
> </Request>
> 
> This would be the same as the two separate requests:
> 
> <Request>
>   <Attributes Category=”MyNiftyCategory”>
>     <Attribute AttributeId=”myIdAttr” includeInResult=”true”>
>       <AttributeValue>ABC</AttributeValue>
>     </Attribute>
>   <Attributes>
>   <Attributes Category=”AnotherCategory”>
>     <Attribute AttributeId=”color”>
>       <AttributeValue>red</AttributeValue>
>     </Attribute>
>   <Attributes>
> </Request>
> 
> <Request>
>   <Attributes Category=”MyNiftyCategory”>
>     <Attribute AttributeId=”myIdAttr” includeInResult=”true”>
>       <AttributeValue>12345</AttributeValue>
>     </Attribute>
>   <Attributes>
>   <Attributes Category=”AnotherCategory”>
>     <Attribute AttributeId=”color”>
>       <AttributeValue>red</AttributeValue>
>     </Attribute>
>   <Attributes>
> </Request>
> 
> If there are two or more categories which are repeated, then it is an error.

Alternatively, we could say that the cross product of the combinations 
will be created, and each evaluated as a separate request.  Using 
simpler syntax just to illustrate:

        <Request>
         <Subject>A</Subject>
         <Subject>B</Subject>
         <Resource>X</Resource>
         <Resource>Y</Resource>
         <Action>Read</Action>
        </Resource>

is interpreted as the following set of Requests:

        <Request>
         <Subject>A</Subject>
         <Resource>X</Resource>
         <Action>Read</Action>
        </Resource>

        <Request>
         <Subject>A</Subject>
         <Resource>Y</Resource>
         <Action>Read</Action>
        </Resource>

        <Request>
         <Subject>B</Subject>
         <Resource>X</Resource>
         <Action>Read</Action>
        </Resource>

        <Request>
         <Subject>B</Subject>
         <Resource>Y</Resource>
         <Action>Read</Action>
        </Resource>

The only reason I can think of for disallowing this is to prevent people 
from making inadvertent errors, so we have to ask whether it is more 
likely that two different repeated categories are an optimized request 
or an error.

Regards,
Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692