Attached are my notes on reading the OGSA proposal at
http://www.globus.org/ogsa/security/authz/OGSA-SAML-authorization-profile-june4.pdf
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
formats.
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
OGSA in relation to XACML
Comments based on
http://www.globus.org/ogsa/security/authz/OGSA-SAML-authorization-profile-june4.pdf
Version: 1.4
Updated: 03/07/28 (yy/mm/dd)
INTRODUCTION
============
"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
initiator.
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
portType.
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?
OVERVIEW OF OGSA SAML EXTENSIONS
================================
- 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.
SPECIFIC OGSA SAML EXTENSIONS
=============================
- Element <AuthorizationDecision>
This element's type extends SAML ResponseAbstractType by adding
the existing saml:Decision attribute to it (Permit, Deny,
Indeterminate).
The purpose of this extension is to meet the requirement for a
simple decision rather than for returning a set of permitted
actions.
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
Statement>
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.
OGSA PROFILED USE OF EXISTING SAML ELEMENTS
===========================================
- 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
might).
- 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
might).
- 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
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. 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.
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.
6.