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: Action implication and propagation in XACML


        ACTION IMPLICATION AND PROPAGATION IN XACML

EXECUTIVE SUMMARY
=================

I do not believe any of the proposed solutions solves the problem
of action propagation.  Expressing simple action implication can
be done with action-match types of functions.

PROBLEM 1: ACTION IMPLICATION
=============================

How to model policies where permission to perform one action
includes ability to perform another action.

EXAMPLE: in some hypothetical system, a Policy granting
permission to perform action X should match actions "X" and "Y".
Or maybe, a Policy granting permission to perform action "X,Y"
should match actions "X", "Y", "X,Y", "Y,X".

ONE SOLUTION: define a function "xy-action-match".  This function
implements the action matching needed.  This does not really seem
to be a big problem, and there are ways to handle it.

PROBLEM 2: ACTION PROPAGATION
=============================

How to model policies where permission to perform an action on
one resource depends on permissions granted to perform actions on
other resources.  The problem can be constrained when associated
with hierarchical resources to say one resource depends on
permissions granted to perform actions on other resources having
a specified hierarchical relationship with the first resource.

EXAMPLE: in Unix File System file permissions, in order to "read"
a file, you must have "execute" permission (search) on all
directories from the file up to the root even if you specifically
have "read" permission on the file itself.

Sample Request: "Anne" wants to "read" file "/x/y/z"

<Request>
  <Subject>
    <Attribute AttributeId="subject-id" DataType="string">
      <AttributeValue DataType="string">Anne</AttributeValue>
    </Attribute>
  </Subject>
  <Resource>
    <Attribute AttributeId="resource-id" DataType="string">
      <AttributeValue DataType="string">/x/y/z</AttributeValue>
    </Attribute>
  </Resource>
  <Action>
    <Attribute AttributeId="action-id" DataType="string">
      <AttributeValue DataType="string">read</AttributeValue>
    </Attribute>
  </Action>
</Request>

How do we phrase a policy that would allow Anne to read that
file, and also captures that she must have "execute" permissions
on "/", "/x", and "/x/y"?

SOLUTION ATTEMPT#1: If we phrase the policy to say Anne must have
these permissions, then the policy looks like

<Rule Effect="Permit">
  <Condition FunctionId="and">
    <!-- execute permission on / -->
    <Apply FunctionId="and">
      <Apply FunctionId="string-equal">
        <SubjectAttributeDescriptor AttributeId="subject-id" DataType="string"/>
        <AttributeValue DataType="string">Anne</AttributeValue>
      </Apply>
      <Apply FunctionId="string-equal">
        <ResourceAttributeDescriptor AttributeId="resource-id" DataType="string"/>
        <AttributeValue DataType="string">/</AttributeValue>
      </Apply>
      <Apply FunctionId="string-equal">
        <ActionAttributeDescriptor AttributeId="action-id" DataType="string"/>
        <AttributeValue DataType="string">execute</AttributeValue>
      </Apply>
    </Apply>
    <!-- execute permission on /x -->
    <Apply FunctionId="and">
      <Apply FunctionId="string-equal">
        <SubjectAttributeDescriptor AttributeId="subject-id" DataType="string"/>
        <AttributeValue DataType="string">Anne</AttributeValue>
      </Apply>
      <Apply FunctionId="string-equal">
        <ResourceAttributeDescriptor AttributeId="resource-id" DataType="string"/>
        <AttributeValue DataType="string">/x</AttributeValue>
      </Apply>
      <Apply FunctionId="string-equal">
        <ActionAttributeDescriptor AttributeId="action-id" DataType="string"/>
        <AttributeValue DataType="string">execute</AttributeValue>
      </Apply>
    </Apply>
    <!-- execute permission on /x/y -->
    <Apply FunctionId="and">
      <Apply FunctionId="string-equal">
        <SubjectAttributeDescriptor AttributeId="subject-id" DataType="string"/>
        <AttributeValue DataType="string">Anne</AttributeValue>
      </Apply>
      <Apply FunctionId="string-equal">
        <ResourceAttributeDescriptor AttributeId="resource-id" DataType="string"/>
        <AttributeValue DataType="string">/x/y</AttributeValue>
      </Apply>
      <Apply FunctionId="string-equal">
        <ActionAttributeDescriptor AttributeId="action-id" DataType="string"/>
        <AttributeValue DataType="string">execute</AttributeValue>
      </Apply>
    </Apply>
    <!-- read permission on /x/y/z -->
    <Apply FunctionId="and">
      <Apply FunctionId="string-equal">
        <SubjectAttributeDescriptor AttributeId="subject-id" DataType="string"/>
        <AttributeValue DataType="string">Anne</AttributeValue>
      </Apply>
      <Apply FunctionId="string-equal">
        <ResourceAttributeDescriptor AttributeId="resource-id" DataType="string"/>
        <AttributeValue DataType="string">/x/y/z</AttributeValue>
      </Apply>
      <Apply FunctionId="string-equal">
        <ActionAttributeDescriptor AttributeId="action-id" DataType="string"/>
        <AttributeValue DataType="string">read</AttributeValue>
      </Apply>
    </Apply>
  </Condition>
</Rule>

But now the Request will have to have four resource-id Attributes
(for /, /x, /x/y, and /x/y/z) and two action-id Attributes
("execute" and "read"), and there is nothing in XACML that
relates the action "read" solely to the resource-id "/x/y/z" and
the action "execute" solely to "/", "/x", and "/x/y".

SOLUTION ATTEMPT#2: We could try to create a new "AttributeId"
that contains an XACML Policy saying Anne has "execute"
permission on each of "/", "/x", and "/x/y".  The Request could
include an instance of this Attribute as an Attribute of the
Subject.

But there is nothing in XACML to allow us to match such input
Policies in a Request Attribute against required values in the
Policy being evaluated.  We could define a new Function that can
compare such input Attribute values (containing Policy fragments)
against required values.  But if Anne wants to list (execute) a
"/x", a new Rule will have to be written, even though her input
Policy Attribute says she already has permission to do that.

SOLUTION ATTEMPT#3: Simon's "first proposal for hierarchical
resources" allows the Policy to contain an element describing the
UFS Resource Model, and indicating that "read" implies "execute"
and that "execute" propagates up.  Now the Policy can say "Anne"
has "read" access to "/x/y/z", and the PDP (if it understands the
UFS Resource Model element) will also know that Anne is allowed
to "execute" "/x" and "/x/y" without having to write separate
expressions for each.

But if the Request is for "Anne" to "execute" "/", then is the
PDP supposed to look for all expressions that match any resource
starting with "/" and action "read" or "search"?  XACML does not
have syntax for expressing these kinds of connections between
resource and action attributes.

Simon supplied examples of specifying Resource Model elements,
but did not give examples of workable and useful policies that
made use of the information in those elements.  I don't see how
the proposal would help in creating such policies.

SOLUTION ATTEMPT#4: Anne tried to create a function like the
solution described for Problem 1 above.  This function would know
that "read" should match "read" and "execute" on any resource
above a stated resource.  Again, XACML does not have syntax for
connecting a particular action with a particular resource in a
way that the PDP can tell they are to be treated as a unit.

CONCLUSION: I do not know of a solution to this problem.

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



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