name problem with XACMLPolicyConstraint

[Anne Anderson - Sun Microsystems <Anne.Anderson@sun.com>]

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