>I'm not sure I understand the question. A service fetches its policies
>from its database, or wherever it stores them, and they are inserted
>into the XACMLAuthzAssertion just as other service-specific information
>is fetched and stored into other WS-Policy Assertions. This is for
>relatively stable authz policies, where the policy can be put into a
>WS-Policy instance and updated only as often as other information in the
>WS-Policy instance might be updated.
>I don't think anyone has designed a standard way for clients to store
>and fetch their authz policies. That is up to the client.
There are several ways, one is defined in WS-PolicyAttachment, others include WS-MetadataExchange, why I
ask this question is because its going to be important how assertions are declared as I want to be
able to fetch based upon fragments and not the whole policy documents.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Anne Anderson - Sun Microsystems <>
Anne Anderson - Sun Microsystems <>
10/10/2006 09:33 AM
Please respond to
To
XACML TC <>
cc
Subject
Re: [xacml] Issue#47: XACML WS-Policy Assertions name problem
Hi Tony,
Anthony Nadalin wrote On 10/10/06 01:28,:
> So what do you think the use cases are ?
I have a list of use cases in the Introduction section of WD 5, which I
submitted yesterday:
Web Services Profile of XACML (WS-XACML) Version 1.0, WD 5, 9 October 2006
http://www.oasis-open.org/committees/download.php/20643/xacml-3.0-profile-webservices-spec-v1.0-wd-5-en.pdf
It is linked off the XACML TC Home Page under "Work in Progress",
replacing the old WSPL link, since this is the successor to WSPL.
> How are policies fetched ?
I'm not sure I understand the question. A service fetches its policies
from its database, or wherever it stores them, and they are inserted
into the XACMLAuthzAssertion just as other service-specific information
is fetched and stored into other WS-Policy Assertions. This is for
relatively stable authz policies, where the policy can be put into a
WS-Policy instance and updated only as often as other information in the
WS-Policy instance might be updated.
I don't think anyone has designed a standard way for clients to store
and fetch their authz policies. That is up to the client.
> Do you see the usage mainly being a policy store -> PDP ?
No. I see it as a service taking the policy it's PDP will use (or a
subset of it) and publishing it for the use of clients in deciding
whether and how to connect with the service. It is not a policy
provisioning mechanism at all.
> How would I include policy in a request (to cover a bootstrap case, I would imagine
> I would want this in a token).
In the new version of the SAML Profile for XACML 3.0, we allow a policy
to be included in an XACMLAuthzDecisionRequest. Such a request could be
included in a SOAP Security header like any other token. Perhaps I
should include that in the next draft of the Profile.
Regards,
Anne
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> Inactive hide details for Anne Anderson - Sun Microsystems
> <>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
>
>
--
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
