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: Notes from OGSA/XACML SAML Req/Resp discussion


Items marked "*" reflect notes taken during the meeting on 21
August 2003.  They are inserted into appropriate places in the
agenda outline.

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

 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?

  * XACML' proposal include request in response.
  * XACML 2.0 work item to include a partially evaluated policy 
    as "Conditions" in the SAML Response.
  * May be good to include in the XACML response, rather than
    depending on SAML.

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

  * Von is more on "attribute request" side.
  * David is more on "establish context" with PDP side.
    Saves retrieving and parsing attributes over again on each
    request.
  * XACML proposal allows PDP to return all information or all
    attributes used in evaluating this request.  Issues about
    whether attributes are still valid on a subsequent request.
    Lack of mechanism for returning validity period, etc.
    Problems with a very dynamic environment, but useful if
    fairly static.
  * CORBA has a "setup" mode.
  * XACML assumes attributes in Request Context have been
    validated.  Front-end might do the validation, and might
    construct the Request Context from a bag of authenticated
    SAML Attribute Assertions.
  * Frank proposes expanding "issuer" to include the entire trust
    chain.  Would like to do the trust validation in XACML,
    cryptographic validation outside XACML.  Doesn't make sense
    to put this information into XACML unless in SAML.  Shouldn't
    this go into X.509 NameConstraints in signing certificate?
    Orthogonal issues to be resolved.  X.509 is trusting
    identity, need other way to trust authority to issue certain
    attributes.  Use XACML policies in X.509 Attribute
    Certificates to indicate who is trusted to issue which
    attributes?  **POSSIBLE WORK ITEM**
  * Way to express policies about what chains you trust in XACML?
    SPKI uses KeyNote for this.

  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?

  * Current SAML returns request info with response, but it isn't
    sufficient.  Subject, Target, Actions returned.  Good to have
    a way to return a simple Decision without the other
    information.  Optionally!  Used in pull mode.

  * A simple decision will never have conditions.  It will have
    the simple identifier of the request.

- Decision values

  * SAML respondWith is deprecated.  Better to use specific flags
    in the request to indicate information options on what to be
    returned.

  * Use of Indeterminate, how to specify a decision subject to
    Conditions has been returned.  "Indeterminate" = "Deny unless
    <Conditions>".

  * Richer return value syntax: grant, deny, grant subject to
    conditions, not applicable, unable to evaluate due to error.
    Simple PEP's may be unable to deal with anything except "yes"
    and "no".  Requester should be able to specify type of
    response: richer or yes/no.  SAML currently uses respondWith,
    but that is deprecated because semantics fuzzy.  Alternative
    is unknown.  OGSA uses respondWith to specify simple/complex
    decision as well as single-step/multi-step.

  * NotApplicable: nice to do on a per-association basis, not on
    a per-request basis.  Returned "Conditions" might include
    that information - involves partially evaluated policies.
    XACML can also return Obligations.

  * XACML proposal uses two flags: "InputContextOnly (use only
    the attributes contained in the request in making the
    evaluation; used for "what if" mode).  "ReturnContext"
    (return minimally all information used in making the
    decision; may return more information).

* Environmental attributes requirement handled satisfactorily by
  XACML Request Context

* Reference statement: credential pull model.  Part of XACML 2.0
  work items.

* Separate semantic requirements from proposed syntactic changes;
  next meeting will be on 28 August during XACML Focus Group
  time; prior to that, participants should submit semantic
  requirements to e-mail list.

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


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