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: WSPL-Eval Overview for TC Meeting 3 Apr 2003


Colleagues,

Attached is an informal overview of my proposal for obtaining
sets of Attribute values that will satisfy an XACML Policy or
PolicySet.  This Overview is not particularly high-level, but it
does provide examples that may be helpful in coming to an
understanding of the approach.  At tomorrow's TC meeting I will
use these examples to illustrate my proposal.

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

Title: WSPL-Eval Overview

WSPL-Eval Overview

This document is an informal overview of WSPL-Eval, my proposal [2] for extracting from an XACML Policy or PolicySet the sets of attributes that will satisfy the policy. For more information and background, please refer to the complete proposal.

Special terms are in bold font. The first time a special term is used, it is also italicized and defined.

Title: An Overview of XACML WSPL Evaluation Author: Anne Anderson Version: 1.2, 03/04/02 (yy/mm/dd) Source: /lab/east/info/projects/isrg/xacml/docs/WSPL/SCCS/s.WSPLEval_Overview.html

Contents

  1. WSPL-Eval Policies
    1. Incoming Traffic
    2. Outgoing Traffic
  2. Example Policy
    1. Policy in English
    2. Policy in XACML
  3. Evaluation Steps
    1. Rewrite Outgoing Policy as a Boolean expression
    2. Convert Boolean expression to an OR of AND's
    3. Optional: optimize the Satisfying Sets
    4. Evaluate Sets for outgoing traffic
    5. Evaluate Sets against other policies
    6. Construct outgoing message
  4. Handling intermediaries
  5. References

  1. WSPL-Eval Policies
  2. WSPL-Eval allows each entity to have two sets of policies: an Outgoing Policy for outgoing traffic (message, transaction, response, etc.) and an Incoming Policy for incoming traffic.

    1. Incoming Traffic
    2. XACML Version 1.0 [4] was written for handling Incoming Policies and for handling incoming traffic. So all incoming traffic is evaluated against the receiver's Incoming Policy using the rules described in the XACML Version 1.0 Specification [4]. Based on this evaluation, it accepts or rejects the message.

    3. Outgoing Traffic
    4. XACML Version 1.0 [4] was not written to handle Outgoing Policies or for handling outgoing traffic. Although the XACML Policy syntax and semantics are suited for describing Outgoing Policies, the XACML Version 1.0 Specification does not give rules for how to evaluate them.

      WSPL-Eval describes these new rules as a series of policy evaluation steps described below .

  3. Example Policy
  4. This explanation of the WSPL-Eval steps uses the following Outgoing Policy example.

    1. Policy in English
    2. In English, the example Outgoing Policy may be stated as follows:

      Rule 1:
      When communicating with "Anne's Web Server", use the identity "Anne H. Anderson" or the role "Owner" and use http.

      Rule 2:
      When making reservations via "Sun Travel Reservations Server", always request a window seat (preferred) or aisle seat (second best) and use my identity of "aa74233".

      Rule 3:
      When communicating with "She Who Must Be Obeyed", do not use the action "Refuse".

      Rule 4:
      Unless otherwise specified, use the identity "Anne Anderson".

    3. Policy in XACML
    4. In XACML, the example Outgoing Policy (syntax simplified) might be:

      <Policy RuleCombiningAlgId="urn:...:deny-overrides>
        <Target>
          <Any>
        </Target>
        <Rule RuleId="1" Effect="Permit">
          <Target>
            <Subjects>
              <Subject>
                subject-id = "Anne H. Anderson"
              </Subject>
              <Subject>
                role = "Owner"
              </Subject>
            </Subjects>
            <Resources>
              <Resource>
                resource-id = "Annes Web Server"
                protocol = "http"
              </Resource>
            </Resources>
            <Actions>
              <AnyAction/>
            </Actions>
          </Target>
        </Rule>
        <Rule RuleId="2" Effect="Permit">
          <Target>
            <Subjects>
              <Subject>
                subject-id = "aa74233"
              </Subject>
            </Subjects>
            <Resources>
              <Resource>
                resource-id = "Sun Travel Reservations Server"
              </Resource>
            </Resources>
            <Actions>
              <Action>
                action-id = "reserve"
                seat-type = "window"
              </Action>
              <Action>
                action-id = "reserve"
                seat-type = "aisle"
              </Action>
            </Actions>
          </Target>
        </Rule>
        <Rule RuleId="3" Effect="Deny">
          <Target>
            <Subjects>
              <AnySubject>
            </Subjects>
            <Resources>
              <Resource>
                resource-id = "She Who Must Be Obeyed"
              </Resource>
            </Resources>
            <Actions>
              <Action>
                action-id = "Refuse"
              </Action>
            </Actions>
          </Target>
        </Rule>
        <Rule RuleId="4" Effect="Permit">
          <Target>
            <Subjects>
              <Subject>
                subject-id = "Anne Anderson"
              </Subject>
            </Subjects>
            <Resources>
              <AnyResource/>
            </Resources>
            <Actions>
              <AnyAction/>
            </Actions>
          </Target>
          <Condition FunctionId="not">
            <Apply FunctionId="any-of-any">
              <ResourceAttributeDesignator
                 AttributeId="resource-id"/>
              <Apply FunctionId="string-bag">
                <AttributeValue>Anne's Web Server</AttributeValue>
                <AttributeValue>Sun Travel Reservations Server</AttributeValue>
              </Apply>
            </Apply>
          </Condition>
        </Rule>
      </Policy>
      
      
         

  5. Evaluation Steps
  6. Outgoing messages and Outgoing Policies are handled according to the following steps.

    1. Rewrite Outgoing Policy as a Boolean expression
    2. WSPL-Eval first re-writes the XACML Outgoing Policy as a Boolean expression. My proposal [2] gives the mapping from each construct in XACML to the corresponding Boolean operator to be used.

      This step needs to be performed only when the Outgoing Policy changes; it does NOT need to be done each time an outgoing message is generated.

      The example policy can be expressed as a Boolean expression as follows:

      AND( OR(
               # Rule 1
               AND( OR( subject-id = "Anne H. Anderson",
                        role = "Owner"),
                    resource-id = "Anne's Web Server",
                    protocol = "http"),
      
               # Rule 2
               AND( subject-id = "aa74233",
                    resource-id = "Sun Travel Reservations Server",
                    OR ( AND( action-id = "reserve",
                              seat-type = "window"),
                         AND( action-id = "reserve",
                              seat-type = "aisle")))),
      
               # Rule 4
               AND ( subject-id = "Anne Anderson",
                     NOT ( any-of-any( resource-id,
                                       BAG( "Anne's Web Server",
                                            "Sun Travel Reservations Server")))),
      
           # Rule 3
           NOT( AND( resource-id = "She Who Must Be Obeyed",
                         action-id = "Refuse")))
      

    3. Convert Boolean expression to an OR of AND's
    4. Any Boolean expression can be converted to an "OR of AND's" (Disjunctive Normal Form) using a well-known algorithm (the algorithm is described nicely, with pictures!, in [1]). There is Open Source code available that does this conversion for database queries [3]; I believe that code can be adapted fairly easily to do the same conversion for XACML.

      This step also needs to be done only when the Outgoing Policy changes; it does NOT need to be done each time an outgoing message is generated.

      By applying the standard algorithm (manually, so I probably made some mistakes) to the policy above, we get:

      OR( AND( subject-id = "Anne H. Anderson",
               resource-id = "Anne's Web Server",
               protocol = "http"),
          AND( role = "Owner",
               resource-id = "Anne's Web Server",
               protocol = "http"),
          AND( subject-id = "aa74233",
               resource-id = "Sun Travel Reservations Server",
               action-id = "reserve",
               seat-type = "window"),
          AND( subject-id = "aa74233",
               resource-id = "Sun Travel Reservations Server",
               action-id = "reserve",
               seat-type = "aisle"),
          AND( subject-id = "Anne Anderson",
               resource-id != "Anne's Web Server",
               resource-id != "Sun Travel Reservations Server",
               resource-id != "She Who Must Be Obeyed",
               action-id != "Refuse"),
          AND( subject-id != "She Who Must Be Obeyed",
               resource-id != "Refuse"))
      

      Each of the AND clauses above specifies an acceptable set of Attributes! And they are ordered by the policy writer's preferences.

      WSPL-Eval refers to the collection of Attributes specified by an AND clause above as a Satisfying Set for the Outgoing Policy.

    5. Optional: optimize the Satisfying Sets
    6. The Satisfying Sets can be optimized in several ways. Each of these optimizations can be done once prior to any outgoing traffic being sent. The optimizations do not need to be re-done unless the Outgoing Policy changes.

      It is not necessary to do these optimizations, but since they can be done ahead of time, it will save time when a particular piece of outgoing traffic must be generated.

      1. Eliminate Satisfying Sets with conflicting Attribute specifications. For example, the following types of Sets may be eliminated:

        Set contains
             subject-id = "Anne Anderson"
             subject-id != "Anne Anderson"
        
        Set contains
             attributeA > 5
             attributeA < 5
        
        Set contains 
             subject-id = "Anne Anderson"
             subject-id = "Homer Simpson"
        
        (unless it is known that a single initiator could have two different identities).

      2. Eliminate redundant predicates.

        For example, if a Satisfying Set contains:

        Attribute A > 5
        Attribute A < 10
        

        that can be simplified to:

        Attribute A > 10
        

      3. Eliminate Satisfying Sets that can never apply for this evaluator. For example, if subject-id values this evaluator are

        { "Anne Anderson", "Anne H. Anderson", "aa74233" }
        

        then eliminate Sets that contain other subject-id values.

    7. Evaluate Sets for outgoing traffic
    8. This is the step that must be done for each piece of outgoing traffic. It uses the results of Steps 1, 2, and 3.

      Certain attribute values for a bit of outgoing traffic are pre-determined. For example, the traffic presumably has a known resource (destination, target) and certain attributes of the action may be known. These pre-determined attribute values are used to select from the collection of Satisfying Sets.

      Evaluate each Satisfying Set in turn, supplying the pre-determined Attribute values and any other Attribute values that can be retrieved. Eliminate Sets where the known Attribute values make one of the predicates FALSE until a Set is found that is not necessarily FALSE. This Set is the preferred Satisfying Set for this piece of outgoing traffic.

      For example, say I want to reserve a flight via the Sun Travel Reservation Server. This pre-determines the value

      resource-id = "Sun Travel Reservations Server"
      

      I evaluate the Satisfying Sets in turn.

      AND( subject-id = "Anne H. Anderson",
           resource-id = "Anne's Web Server",
           protocol = "http")
      
      AND( role = "Owner",
           resource-id = "Anne's Web Server",
           protocol = "http")
      

      are eliminated, since the resource-id makes that predicate necessarily FALSE.

      But,

      AND( subject-id = "aa74233",
           resource-id = "Sun Travel Reservations Server",
           action-id = "reserve",
           seat-type = "window")
      

      is not necessarily FALSE, since the predicates for which Attribute values are known evaluate to TRUE. This is my preferred Satisfying Set for this particular piece of outgoing traffic.

      There is a second Satisfying Set for this piece of outgoing traffic. I do not need to evaluate past the first one unless I discover that my first Set will not work for some reason.

    9. Evaluate Sets against other policies
    10. Often, more than one Policy must be satisfied. Perhaps my outgoing traffic must conform to Sun's corporate policies as well as to my own preferences. Or, more commonly, my outgoing traffic must conform to the Incoming Policy of the destination for my traffic.

      Additional Policies merely constrain the initial Satisfying Sets further; they can never add new Satisfying Sets. Therefore, in order to determine whether a given Satisfying Set also satisfies another Policy, it is sufficient to evaluate the other Policy using the rules in XACML Version 1.0 [4] and supplying the Attribute values in the Satisfying Set along with any other Attribute values that may be called for. If these values do not result in "Permit" decision, then the next most preferred Satisfying Set should tested. Continue until a Satisfying Set (plus additional Attribute values) results in a "Permit" decision. This will be the originator's most-preferred Satisfying Set that also satisfies the additional Policy. If no Satisfying Set also satisfies the additional Policy, then there is no mutually acceptable set of values that satisfies both Policies.

    11. Construct outgoing message
    12. The Attribute values in the selected Satisfying Set are now used to construct the outgoing message. Some of the values will be used by the message constructor to determine the actual message (such as whether it will be encrypted), while other values will be passed with the message as Attribute values.

  7. Handling intermediaries
  8. Some of the use-cases in [5] (Use-case 5: Subsequent processing, Use-case 6: Intermediary request, Use-case 7: Intermediary response, Use-case 10: Third party combines) involve an intermediary, who, when it generates outgoing traffic based on a piece of incoming traffic, must satisfy the Outgoing Policy of the originator of the incoming traffic as well as its own Outgoing Policy.

    WSPL-Eval handles these situations by having the intermediary first construct its own Satisfying Sets from its own Outgoing Policy. These Sets are then evaluated against the the originator's Outgoing Policy until a Set that satisfies both is determined. The originator may send along a copy of its Outgoing Policy, possibly in the form of the collection of Satisfying Sets that apply to this traffic.


  9. References
  10. [1] E. Spyropoulou, et al., "KeyNote Policy Files and Conversion to Disjunctive Normal Form for Use in IPsec", Center for Information Systems Security Studies and Research, Computer Science Department, Naval Postgraduate School, Monterey, CA, January 2002, http://cisr.nps.navy.mil/downloads/Project_KeyNote.pdf.

    [2] A. Anderson, "Evaluating XACML as a Policy Language", Working Draft 03, 24 March 2003, http://lists.oasis-open.org/archives/xacml/200303/msg00057.html.

    [3] "Solaris WBEM SDK Developer's Guide", Class "QueryExp" method "canonizeDOC" (sic), http://wbemservices.sourceforge.net/WBEMSDKDG_html/p25.html.

    [4] T. Moses, et al., "OASIS eXtensible Access Control Markup Language (XACML) Version 1.0", OASIS Standard, 18 February 2003. http://www.oasis-open.org/committees/xacml/repository/oasis-xacml-1.0.pdf.

    [5] T. Moses, "Web-services policy language use-cases and requirements", Working draft 03, 21 March 2003. http://www.oasis-open.org/committees/download.php/1378/wd-xacml-wspl-use-cases-03.pdf.


Anne Anderson
Last modified: Wed Apr 2 15:11:16 EST 2003

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