So what do you think the use cases are ? How are policies fetched ? Do you see the usage mainly being a policy store -> PDP ? How would I include policy in a request (to cover a bootstrap case, I would imagine I would want this in a token).
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Anne Anderson - Sun Microsystems <>
Anne Anderson - Sun Microsystems <>
09/14/2006 10:10 AM
Please respond to
; Please respond to
To
XACML TC <>
cc
Subject
[xacml] 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:
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
From - Wed
