Subject: Notes on OGSA SAML AuthorizationDecisionQuery/Response changes
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.