OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] ForAny Procedural ? Was:Re: How to get attributes from other categories


Hi,

Catching up late with this discussion...

I agree with Steven that a general purpose mechanism for handling of relationships is better than a bunch of case-by-case functions, which will grow over time, and which we will have trouble to anticipate what to put in the spec.

The key point in my opinion is that the expressions on relations must be possible to execute remotely in a PIP, rather than having to pull the data into the PDP for looping. I know that users out there have relations which have many thousands of entries.

Ideally, the XACML relation concept and language should be translatable to, say SQL, for easy, efficient and practical execution/implementation.

Best regards,
Erik


On 2013-08-21 08:52, Steven Legg wrote:

Hi Rich,

On 15/08/2013 4:09 PM, rich levinson wrote:
The motive is to try to keep the policy language more or
less "declarative" in its current form and to use the functional
programming methods to enable the features you have
proposed.

ForAny is just the existential quantifier of predicate logic, which I
don't normally regard as procedural, but which in any case is no more
procedural than what is already in XACML. Of course, the question is
mostly academic since few users will understand the distinction we are
talking about, let alone care.

As a thought experiment, let's go back to this example:

    <ForAny VariableId="$org">
      <!-- $org is bound to each organization URI in turn -->
      <AttributeDesignator
        Category="access-subject"
        AttributeId="organization"
        DataType="anyURI"
        MustBePresent="false"/>
      <Apply FunctionId="and">
        <Apply FunctionId="boolean-is-in">
          <AttributeValue DataType="boolean">true</AttributeValue>
          <Apply Function="attribute-designator">
            <VariableReference VariableId="$org"/> <!-- CategoryId -->
<AttributeValue DataType="anyURI">organization-np<AttributeValue> <!-- AttributeId --> <AttributeValue DataType="anyURI">boolean</AttributeValue> <!-- DataType --> <AttributeValue DataType="boolean">false</AttributeValue> <!-- MustBePresent -->
          </Apply>
        </Apply>
        <Apply FunctionId="boolean-is-in">
          <AttributeValue DataType="boolean">true</AttributeValue>
          <Apply Function="attribute-designator">
            <VariableReference VariableId="$org"/> <!-- CategoryId -->
<AttributeValue DataType="anyURI">organization-np<AttributeValue> <!-- AttributeId --> <AttributeValue DataType="anyURI">boolean</AttributeValue> <!-- DataType --> <AttributeValue DataType="boolean">false</AttributeValue> <!-- MustBePresent -->
          </Apply>
        </Apply>
      </Apply>
    </ForAny>

Suppose I had a function called is-both-np-and-us that implemented the
"and" expression above. Using that function I could reproduce the effect
of this particular ForAny expression using the any-of function like so:

    <Apply FunctionId="any-of">
      <Function FunctionId="is-both-np-and-us"/>
      <AttributeDesignator
        Category="access-subject"
        AttributeId="organization"
        DataType="anyURI"
        MustBePresent="false"/>
    </Apply>

Nothing remarkable there.

I could define the is-both-np-and-us function in prose, but using an XACML expression is more precise. However, to do that formally I need a way to indicate where the function's argument fits into the expression. I have chosen to use
a VariableReference expression to do that, but I could define a new
ParameterReference expression to do it instead, if folks prefer. My function
definition might look something like this on paper:

    is-both-np-and-us

This function takes a single argument of data type "anyURI" indicated by
    the variable name "$org". It SHALL return the "boolean" result of
    evaluating the following XACML expression:

      <Apply FunctionId="and">
        <Apply FunctionId="boolean-is-in">
          <AttributeValue DataType="boolean">true</AttributeValue>
          <Apply Function="attribute-designator">
            <VariableReference VariableId="$org"/>
<AttributeValue DataType="anyURI">organization-np<AttributeValue>
            <AttributeValue DataType="anyURI">boolean</AttributeValue>
            <AttributeValue DataType="boolean">false</AttributeValue>
          </Apply>
        </Apply>
        <Apply FunctionId="boolean-is-in">
          <AttributeValue DataType="boolean">true</AttributeValue>
          <Apply Function="attribute-designator">
            <VariableReference VariableId="$org"/>
<AttributeValue DataType="anyURI">organization-np<AttributeValue>
            <AttributeValue DataType="anyURI">boolean</AttributeValue>
            <AttributeValue DataType="boolean">false</AttributeValue>
          </Apply>
        </Apply>
      </Apply>

There is nothing about this function that is unprecedented, except perhaps the method of its definition. It is more complicated that the average XACML function, but it is nowhere near as complicated as the XPath-based functions, which process arbitrarily complex XPath expressions. The fact that is-both-np-and-us pulls information out of the request context is unusual, but the XPath-based functions
also do that.

It is of course no accident that the expression defining the is-both-np-and-us function is identical to the second child of the original ForAny expression. Consequently, one way to view the ForAny expression is as a form of the any-of function with an in-line, anonymous function definition instead of the identifier of a pre-existing function. The flexibility to define in-line, anonymous functions doesn't make the language more procedural, it just makes it easier to create
functions!

Regards,
Steven



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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]