XACML/OGSA SAML AuthzDecisionQuery/Resp Working Session 21 Aug

Colleagues,

We need an agenda of items to cover at our 21 August meeting in
order to use the time productively.  I propose the following: use
the current XACML proposal (attached) as a base, with changes or
additions needed to support the OGSA requirements as issues to be
resolved.  I have started a list of the OGSA requirements that
are not met by the existing XACML proposal below.  We can decide
on the order in which to start addressing these at the meeting.
We won't get to all of them, but we can make a start.

Note that changes might involve the SAML
AuthzDecisionQuery/Response wrapper, the XACML Request/Response
payload, or other protocols, new or existing.

Any other suggestions?

-Anne Anderson

I use "attribute" to mean the same thing (I hope) as
"credential".  [x] indicates a proposed solution at the bottom.

- decision push mode: any changes needed to support this?

- attribute pull mode (PDP pulls initiator's attributes from
  some other authority)

  o Way for client to provide pointer to the authorization
    service, giving it a hint where to find attributes

- Multi-step authorization

  o Way for a set of attributes to be collected for a given
    subject and re-used in a sequence of subsequent
    AuthorizationDecisionQueries.  Where is this state
    maintained?

  o Format for such a collection of attributes (a skeleton XACML
    Request?)

- Linking an AuthorizationDecision to the set of information
  contained in the Query to which it is a response.

  o Is XACML proposal option for including the entire Request in
    the AuthzDecision sufficient?  Does the unique ID in the SAML
    AuthorizationDecisionQuery need to be included in the
    AuthzDecision?  Does each XACML Request need its own unique
    ID?

- Multiple actions in a single request. [1,2]
  
  o Is Decision all-or-nothing? or a separate decision for each
    action?  If separate, how do decisions specify action to
    which they pertain?
    
- Multiple resources in a single request. [1,2]

  o Is Decision all-or-nothing? or a separate decision for each
    resource?  If separate, how do decisions specify action to
    which they pertain?  (XACML already supports multiple
    resources in a decision, but not in a Request).

- Decisions where not all information was available.  How to
  indicate that SAML Decision contains Conditions that must also
  be satisfied.  Format for those Conditions (XACML Policy?) [3]

- #X509SubjectName DataType: will XACML support this as a base
  DataType?  If so, will it replace the current XACML x500Name
  DataType?  Are comparison semantics the same?

- Returning subject's rights to all resources of which the PDP is
  aware (wildcard resource URI).

- Returning subject's rights to take all actions that apply to a
  specified resource.

Possible solutions:
[1] Multiple Actions, Associate Actions with Resource: It might be
   useful for the XACML Request to be of the form

     Subject Attributes
     Requested Permission 1
       Resource
         Resource Attributes
       Action
         Action Attributes
     Requested Permission 2
     ...

   where each Requested Permission contains a resource and an
   action, along with their attributes.  The XACML Response
   should then be modified to return a Decision for each
   "Requested Permission", identifying the "Requested
   Permission".  This would meet the need that various users have
   expressed for multiple actions, or for getting multiple
   decisions per Request.  [It does not solve the Hierarchical
   Resource problems, but certainly does not make them worse :-)]

   The evaluation model would be to run the current evaluation
   model once for each Requested Permission.

[2] Semantics for multiple resources and/or actions might be
  specified as: PDP runs the current evaluation engine once for
  each resource/action pair.  Depending on a flag set by the PEP,
  either a single decision is returned ("Permit" only if every
  resource/action pair evaluated to "Permit") or a separate
  decision is returned for each, using existing XACML Response
  multiple-decision format, but specifying action-id as well as
  resource-id to which each decision applies.

[3] Partial Evaluation: It might be useful to define "partial
   evaluation" for XACML, both for debugging purposes and for
   applications such as returning "Conditions".  By "partial
   evaluation", I mean using all available attributes to resolve
   and factor out predicates that can be eliminated, leaving a
   Policy that that contains only predicates that depend on
   unavailable attributes.  For example, if the Rule is:

   <Rule Effect="Permit">
      <Condition FunctionId="and">
        <Apply FunctionId="string-equals">
           <AttributeValue>X</AttributeValue>
           <SubjectAttributeDesignator AttrId="subject-id">
        </Apply>
        <Apply FunctionId="string-equals">
           <AttributeValue>Y</AttributeValue>
           <ResourceAttributeDesignator AttrId="resource-id">
        </Apply>
      </Condition>
    </Rule>

   and a Resource Attribute for resource-id with value "Y" is
   supplied, but there is no subject-id attribute available, then
   the Rule, given the input Context, simplifies to

   <Rule Effect="Permit">
      <Condition FunctionId="string-equals">
         <AttributeValue>X</AttributeValue>
         <SubjectAttributeDesignator AttrId="subject-id">
      </Condition>
   </Rule>

   I can think of lots of problems in defining useful "partial
   evaluation" rules, but I can also think of lots of useful
   cases.

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