Re: [xacml] Issue#47: WS-Policy Assertion profile for XACML

[Anne Anderson <Anne.Anderson@sun.com>]

Hi Tony,

Including an XACMLPolicyAssertion in a WS-Policy instance is a way for a 
service to declare its access control / authorization policy.  It 
describes a "requirement of a policy subject" - its authorization 
requirement - so I think is a true assertion in the WS-Policy sense. 
Clients can use this Assertion to determine what attributes or message 
field values they would need to provide in order to access the service, 
and ultimately whether they would be authorized to access the service.

Yes, you will be matching on the strong type 
<xacmlws:XACMLPolicyAssertion>, and this should be sufficient.  The 
inner matching/intersection for any assertion is domain-specific anyway.

In a client<->service usage scenario, the matching would probably be 
asymmetric: the client's access control "constraints and capabilities" 
would probably not be expressed in the form of an XACML policy.  The 
match would not be done against two instances of an 
XACMLPolicyAssertion, but instead between a service's 
XACMLPolicyAssertion and the client's message, which might contain SAML 
Attribute Assertions as "authorization tokens", for example.

If 2) [below] is implemented, then the matching operations defined in 
the XACML profile for web-services (WSPL) could be used.  This might be 
appropriate for expressing very simple authorization policies on both 
the client and the service sides.

In a service composition scenario where multiple XACML policies must be 
satisfied, the policies in their XACMLPolicyAssertions could be composed 
using a combining algorithm.

I've received a number of queries about how an XACML policy will be 
included in a WS-Policy instance, so I think there is a real need for a 
standard way to do this.

Regards,
Anne

Anthony Nadalin wrote On 07/27/06 10:35,:
> So it looks like these are not really assertions but rather just a way 
> to carry xacml statements in a wsp:policy element, why I say this is 
> that all you will be matching on is <xacmlws:XACMLPolicyAssertion 
> Optional="False">.
> 
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> Inactive hide details for Anne Anderson <Anne.Anderson@sun.com>Anne 
> Anderson <Anne.Anderson@sun.com>
> 
> 
>                         *Anne Anderson <Anne.Anderson@sun.com>*
> 
>                         07/26/2006 01:29 PM
>                         Please respond to
>                         Anne.Anderson@sun.com
> 
> 	
> 
> To
> 	
> OASIS XACML TC <xacml@lists.oasis-open.org>
> 
> cc
> 	
> 
> Subject
> 	
> [xacml] Issue#47: WS-Policy Assertion profile for XACML
> 
> 	
> 
> 
> Colleagues,
> 
> Now that WS-Policy has been submitted to and accepted by the W3C, it
> seems like we should have a standard way to carry an XACML Policy or
> PolicySet as an Assertion in a WS-Policy instance.  I'm thinking of
> something like a very simple wrapper:
> 
> <xacmlws:XACMLPolicyAssertion Optional="False">
>   <xacml:PolicySet ...>
>     ...
>   </xacml:PolicySet>
> </xacmlws:XACMLPolicyAssertion>
> 
> Two other possible inclusions might be:
> 
> 1) A signed SAML Assertion containing an instance of the
> XACMLAuthzDecisionStatementType that includes the corresponding Request
> Context; for use as an authorization credential.
> 
>   <xacmlws:XACMLAuthzCredential>
>      <saml:Assertion>
>         ... (containing XACMLAuthzDecisionStatementType instance)
>      </saml>
>   </xacmlws:XACMLAuthzCredential>
> 
> 2) Individual XACML <Apply> statements, for expressing individual
> authorization constraints.
> 
>   <xacmlws:XACMLAuthzAssertion ...>
>       <xacml:Apply FunctionId="...">
>          ...
>       </xacml:Apply>
>   </xacmlws:XACMLAuthzAssertion>
> 
> I've added this as Issue#47 to the Issues list at
> http://wiki.oasis-open.org/xacml/IssuesList
> 
> Regards,
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 

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