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 on OGSA SAML AuthorizationDecisionQuery/Response changes

Attached are my notes on reading the OGSA proposal at

I would like to see if the XACML TC can meet jointly with the
authors of this proposal (Von Welch, Frank Siebenlist, Sam Meder,
Laura Pearlman, David Chadwick) to see if we can come up with a
joint proposal to SAML that would satisfy both OGSA and XACML.  I
will also send these notes/comments to the authors.

I think it unlikely that SAML would adopt two different new

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

OGSA in relation to XACML
Comments based on

Version: 1.4
Updated: 03/07/28 (yy/mm/dd)


"There are a number of authorization systems currently available
for use on the Grid as well as in other areas of computing, such
as Akenti [Akenti], CAS [CAS], PERMIS [PERMIS], VOMS [VOMS]."

  XACML should be added to this list.

decision push mode: authorization system acts as a service,
issuing authorization decision in form of authorization
assertions that are pushed to the target resource by the

  I think this means that the SAML Decision serves as a
  "capability" that is presented to the resource by the
  initiator/application.  A signed SAML
   AuthorizationDecisionStatement using the proposed XACML
   Response format that includes the XACML Request could be used
   for this purpose.

decision pull mode: authorization system linked with an
application or service and acts as a policy decision maker for
that application, which pulls a decision from them.

  This is the XACML model.  No changes needed.

credential push mode: client provides all the information
necessary for a decision to be made.

  XACML can handle this.

credential pull mode: client provides everything except the
initiator's privileges, and the authorization service then pulls
these privilege tokens (or credentials) from some other
authority, and bases its decision on them.  The client may
provide a pointer to the authorization service, giving it a hint
where to find the privileges, or the authorization service may be
pre-configured with knowledge about where to locate them.

  XACML handles the first part fine: the PDP is allowed to pull
  subject credentials from another authority (although it would
  need at least the subject-id in order to get them).

  XACML does not provide a way for the client to provide a
  pointer to the authorization service (PDP) on where to find
  privileges.  This might be useful in XACML.

  It looks as if "privileges" are the same thing as "attributes".
  Is there a difference?

OGSA authorization services are Grid Services providing
authorization functionality over an exposed Grid Service

  An XACML PDP could do this, possibly requiring some
  intermediate translation of the Request/Response, unless the
  XACML SAML proposals are accepted.

Two types of process for authorization in OGSA:

1. Single-step: all information about the requested access is
   passed in one SAML request to the authorization service.

2. Multi-step: the initial SAML request obtains information about
   the initiator, while subsequent SAML requests pass that
   information along with information about the actions and
   targets that the initiator wants to access.

   At a later point in the document, it appears that the PDP
   generates a cookie that refers to the set of attributes
   generated by the first SAML request.  Subsequent request
   merely reference that cookie.  This requires a stateful PDP,
   something XACML has not wanted to require.  One of the authors
   suggests putting the state into an OGSA service, rather than
   in the PDP, and I would agree that this is a better approach.

  Isn't the first stage of multi-step really an "attribute
  request", properly directed to an Attribute Authority, and not
  an "authorization decision request" to be directed to an
  authorization service?

  The type of information conveyed in the first stage of the
  multi-step process is very similar to an XACML Request: lists
  of attributes for Subject(s) [, Resource, Action].  Can XACML
  Context Request be leveraged for use here?  I.e., could an
  Attribute Authority return an XACML Request Context as its
  response to some as-yet-to-be-defined AA Request?


- Simple Authorization Query Response

  The SAML 1.0 model is that the response contains a list of ALL
  the actions that the requester is authorized to perform.

  OGSA proposes including a reference to the
  AuthorizationDecisionQuery in the AuthorizationDecision so that
  the resource can tell that the specific actions in the query
  were authorized.

  The XACML 1.0 Request format already supports only a single
  action per request, and the Response is a simple decision with
  respect to that action.

  The XACML SAML proposal also supports a flag in the SAML
  AuthorizationDecisionQuery requesting that the original XACML
  Request be included in the response.  This further addresses
  the OGSA requirement.

  SUMMARY: The XACML SAML proposes meets the OGSA requirements
  with the possible exception of supporting a single request
  containing multiple actions (it is not clear whether this is an
  OGSA requirement).  The OGSA proposal depends on the
  "RespondWith" element that is deprecated in SAML 1.1, so it has
  a problem already.

- Multi-Stage Authorization

  There are actually two OGSA concepts included here.  First is
  having a separate type of AuthorizationDecisionQuery that is
  supposed to return a set of attributes for a subject.  The
  second is to add state to the PDP, such that the PDP could
  "remember" such a set of subject attributes and apply them to
  requests about multiple resource/actions can be submitted
  regarding the same subject, without having to process the
  subject's attributes again.

  SUMMARY: The XACML SAML proposal does not meet this
  requirement.  Von Welch (OGSA proposal co-author) suggests
  exploring using stateful OGSA service instances for this
  instead of a context state in an attribute.  I agree.  I also
  think requests for subject attributes belong in a separate type
  of query, which would be made to an Attribute Authority, and
  not in an AuthorizationDecisionRequest made to a PDP.


- Element <AuthorizationDecision>

  This element's type extends SAML ResponseAbstractType by adding
  the existing saml:Decision attribute to it (Permit, Deny,

  The purpose of this extension is to meet the requirement for a
  simple decision rather than for returning a set of permitted

  SUMMARY: the XACML proposal satisfies this requirement.  It
  already returns a specific decision in response to a specific
  subject/resource/action request.  XACML can return the entire
  Policy tree in the Conditions element as "conditions that MUST
  be fulfilled before the authorization can be permitted".

  The OGSA proposal attaches a different meaning to
  "Indeterminate" than XACML (and, I think, SAML) has done.  In
  the OGSA proposal, if Indeterminate is returned, then the
  encapsulating assertion MUST also have a Conditions element
  present expressing the conditions that MUST be fulfilled before
  the authorization can be permitted.  This does not allow for
  our use of Indeterminate to return various error conditions.

- Element <Reference

  A new element based on SubjectStatementAbstractType where
  issuer states that "designated attributes associated with a
  specified subject may be obtained form the referenced URI.  Its
  purpose is to advise the PDP where it may find attributes
  associated with the subject, and it is used to support the
  credential pull mode of operation."

  SUMMARY: this could be provided independently of new
  AuthorizationDecisionQuery/Response formats.  It might be
  useful in the XACML context.


- Element <AuthorizationDecisionQuery>

  Differences from XACML model:
  o More than one Action element allowed
  o RespondWith element required to indicate which of the 8 types
    of OGSA authorization service are requested (combinations of
    single/multi-step, credential push/pull, return
    AuthorizationDecision or AuthorizationDecisionStatement)

- #X509SubjectName DataType

  This is apparently a newly defined SAML data type.  OGSA
  defines an empty string for this type as a wildcard meaning
  "anyone" (a decision about public rights is being requested).
  OGSA says subject names SHOULD be X.509 names.

  XACML handles public rights by allowing policies that do not
  specify a subject-id.

- Element <Resource>

  Only real difference from XACML is definition of a "wildcard"
  resource URI.

  In a query this means that the response should indicate the
  initiator's rights on all resources of which the authorization
  service (PDP) is aware; typically used for caching.  Perhaps
  XACML could handle this by returning the entire policy tree.

  In a response, this means the initiator has the given
  privileges on all resources that accept this authorization
  service as authoritative.  XACML does not handle this ( WSPL

- Element <Action>

  Only real difference form XACML is definition of a "wildcard"
  action URI.

  In a query, this means that the response should indicate all
  the initiators rights on the specified resource; typically used
  for caching.  Perhaps XACML could handle this by returning the
  entire policy tree.

  In a response, this means that the initiator has all privileges
  on the specified resource.  XACML does not handle this (WSPL

- Element <Evidence>

  In a query using "single step authorization", OGSA specifies
  that Evidence can hold environmental parameters.  XACML handles
  this with Environment Attributes.

  In the second and subsequent steps of multi-step authorization,
  the Evidence element is used to hold the subject attributes
  returned by the PDP in response to the first step.  XACML can
  handle this by having the requester include the same set of
  subject Attributes in each Request.

  In other cases, the Evidence element is used to hold subject
  credentials or attributes.  I believe the XACML Subjects
  element in the Request can handle these requirements.

  The OGSA proposal allows the OGSA-defined ReferenceStatement
  element also to be included in an Evidence element.  XACML does
  not define an equivalent for a ReferenceStatement (see above).

- Element <RespondWith>

  The OGSA proposal uses the deprecated <RespondWith> element to
  signal the type of authorization decision service requested.

  See comments above about XACML and the various types of
  authorization decision service.

- Element <Assertion>

  Nothing here that conflicts with XACML.  The OGSA proposal
  spells out use of <Conditions>, <Advice>, <Signature>,
  <AuthorizationDecisionStatement>, <AttributeStatement> in an
  <Assertion>, but not in any unusual way.

- Element <Conditions>

  The OGSA proposal suggests using this for optional time
  constraints or for policy conditions that the authorization
  service was unable to evaluate due to insufficient
  information.  "It is envisioned that future specification will
  be able to extend the Condition element to return fine-grained
  policies for parameters on operation invocation and service
  data access, using for example elements of XACML."

  Sounds good to me :-)

XACML 2.0 Ideas

These are ideas for XACML 2.0 changes triggered by various
requirements in the OGSA proposal.

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 Attributes
         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. 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">
           <SubjectAttributeDesignator AttrId="subject-id">
        <Apply FunctionId="string-equals">
           <ResourceAttributeDesignator AttrId="resource-id">

   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">
         <SubjectAttributeDesignator AttrId="subject-id">

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

3. XACML PDP portType: Is it time for XACML to define a portType
   for an XACML PDP? The format for the request/response would be
   SAML XCAuthorizationDecisionQuery and XCResponse.

4. Information Pointers: XACML does not provide a way for the
   client to provide a pointer to the authorization service (PDP)
   on where to find privileges.

   Neither XACML nor OGSA provides a way for the *policy writer*
   to provide a pointer to the authorization service on where to
   find privileges.  The policy writer may be the one in the best
   position to specify where the attributes the policy writer is
   using in policies are to be found: which attribute authorities
   are trusted, how mapping is done between attributes in that
   locations format into XACML policy format, protocol by which
   attributes are retrieved from the location, how attributes are
   located using other attributes whose values are known to the
   authorization service (e.g. subject-id).

   I proposed this at one point, and I think it is time to
   revisit this.  It could be an optional element in a Request or
   in a Policy.

5. X500 Names: SAML has apparently now defined a URI for X509
   Subject Names (#X509SubjectName).  It would be nice for XACML
   and SAML to align on this, especially on the definitions for
   how they are matched, etc.


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