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?)  - #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:  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.  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.  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.