[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue#47: XACML WS-Policy Assertions name problem
[this is a resend with a more descriptive Subject line] Here are some thoughts on the problem of how to deal with the Assertion Type of an XACMLPolicyAssertion, XACMLAuthzCredential, or an XACMLAuthzAssertion. The problem is how a client should match the client's policy or implicit policy against the service's policy where these XACML Assertions are used. "The policy assertion type is identified only by the XML Infoset [namespace name] and [local name] properties (that is, the qualified name or QName) of the root Element Information Item representing the assertion. Assertions of a given type MUST be consistently interpreted independent of their policy subjects." Again, the three proposed new Assertion types are: - XACMLPolicyAssertion: contains an entire XACML Policy or PolicySet representing the authorization or access control policy that a service wishes to publish externally. It may well be a subset of the actual policies used internally. We would specify that no more than one XACMLPolicyAssertion can be used in a single WS-Policy alternative (one acceptable combination of Assertions). - XACMLAuthzCredential: contains an XACML authorization decision in the form of a SAML Assertion containing an instance of an XACMLAuthzDecisionStatementType. The instance should contain the associated Request Context in order to provide the proper context for the decision. This Assertion is used to either require or provide an authorization token or credential that is in the form of an XACML authorization decision. - XACMLAuthzAssertion: a constraint on an individual authorization vocabulary element in the form of an XACML <Apply> element. A set of these would be used to express simple authorization requirements. PROPOSED MATCHING SOLUTIONS 1. XACMLPolicyAssertion: I don't think this is a problem. The format can allow an empty XACMLPolicyAssertion for use by a client indicating that the client is willing to conform to an XACML Policy. The generic policy processor would match only on the type <XACMLPolicyAssertion>. It would be up to the client to decide how to use the service's policy instance. Since we would allow no more than one XACMLPolicyAssertion per policy alternative, there is no need to merge or combine multiple Assertions of this type. 2. XACMLAuthzCredential: I also don't think this is a problem. Again, the generic policy processor would match only on the type <XACMLAuthzCredential>. A service could specify an empty XACMLAuthzCredential to indicate the service requires this type of credential, or a full XACMLAuthzCredential indicating that for a request containing the included Request Context Attributes, the service will require an XACMLAuthzCredential signed by a trusted PDP (WS-Trust might be used to negotiate these). If a client has multiple XACMLAuthzCredentials, that is the same as having multiple instances of any other type of credential - it is up to the service's domain-specific Assertion handler to deal with specific matches. 3. XACMLAuthzAssertion: The matching would use the semantics currently defined in our WSPL Working Draft, from which we would copy. The profile would recommend that the FunctionIds used be from the WSPL set. The generic policy processor would simply verify that a policy alternative from each party contains at least one instance of an XACMLAuthzAssertion and would pass the entire set of XACMLAuthzAssertion elements in each policy to the domain-specific XACML Assertion processor for detailed matching. The XACML Assertion processor would match the elements in two different policies using the table of matching semantics we would copy from the WSPL Working Draft. There are at least two ways we might express the "type" of an XACMLAuthzAssertion for matching purposes: a. Express these Assertions in the form <xacml:Apply ...> (i.e. standard XACML syntax). The generic policy processor would just verify that each policy alternative has at least one instance of an XACMLAuthzAssertion, and pass them to the domain-specific XACML Assertion processor to sort out. WS-Policy states "A policy alternative MAY contain multiple assertions of the same type. Mechanisms for determining the aggregate behavior indicated by the assertions (and their Post-Schema-Validation Infoset (PSVI) content, if any) are specific to the assertion type and are outside the scope of this document." b. Express these Assertions in a form that creates an Assertion type from their AttributeId or AttributeSelector value. This would allow the generic policy processor to do one more level of Assertion matching. We could put a wrapper around the <xacml:Apply> that contains the Assertion type information, or could supply XSLTs that transform an <xacml:Apply> to the form <...AttributeId... DataType=".." FunctionId=".."> with either an AttributeValue or another AttributeId inside. In other words, the AttributeId would be converted into the type of the XACML Assertion in some standard way. Where there are two AttributeIds in the <Apply> instance (for example, requiring one authorization value to be greater than another, perhaps two Assertions would be created, each with the type of one of the AttributeIds. For AttributeSelectors, we would need a way to map an XPath identifier onto Assertion types, and this may be a bigger problem. Could this be done by creating a unique xmlns id (random#?) in the header, setting it equal to the XPath expression, and then using just the id in the Assertion? Can an Assertion have no [local name]? Or could take last digit of id as [local name]. 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 From - Wed
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]