Re: [xacml] Issue#47: XACML WS-Policy Assertions name problem

[Anthony Nadalin <drsecure@us.ibm.com>]

Anne,

Here are my comments on your draft (as pdf markups)

(See attached file: xacml-3.0-profile-webservices-spec-v1.0-wd-5-en-ajn.pdf)

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Anne Anderson - Sun Microsystems <Anne.Anderson@sun.com>

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

10/10/2006 09:33 AM

Please respond to
Anne.Anderson@sun.com

To	XACML TC <xacml@lists.oasis-open.org>
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.com>Anne Anderson - Sun Microsystems
> <Anne.Anderson@sun.com>
>
>
>                         *Anne Anderson - Sun Microsystems
>                         <Anne.Anderson@sun.com>*
>
>                         09/14/2006 10:10 AM
>                         Please respond to
>                         Anne.Anderson@sun.com; Please respond to
>                         Anne.Anderson@sun.com
>
>
>
> To
>
> XACML TC <xacml@lists.oasis-open.org>
>
> 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: 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
>
>

--
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

xacml-3.0-profile-webservices-spec-v1.0-wd-5-en-ajn.pdf