Re: [xacml] New Issue#61: WS-XACML: How are the contents ofXACMLAuthzAssertions represented in the base XACML Policies

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

Hi Rich,

Thanks for the endorsement.

As for identifying WS-XACML policies, I had not considered the problem, 
but it sounds like proposals might be useful.

What occurs to me is to have all WS-XACML policies collected into a 
special PolicySet that is combined with other internal 
PolicySets/Policies so all are evaluated if necessary to reach a result.

The WS-XACML PolicySet could have an identifier that uses a special 
site-specific naming convention: e.g. 
urn:somecompany:...:xacmlauthzassertion:policyset:20

Isolated <Apply> elements don't occur in normal XACML, so for 
Requirements, they should be expressed as a Policy in the form described 
in Section 3.2.  For Capabilities, they should be expressed as a similar 
Policy, except using ...:function:or rather than ...:function:and to 
combine the <Apply> elements (I will add this equivalence to the next 
Revision).  Again, a site-specific naming convention could be used to 
notify the XACML...Assertion builder that the <Apply> elements from that 
policy MAY be extracted: e.g.
urn:somecompany:...:xacmlauthzassertion:requirements:25
urn:somecompany:...:xacmlauthzassertion:capabilities:25

Requirements and Capabilities that "go together" could be put into 
individual PolicySet instances inside the "WS-XACML PolicySet".

That certainly isn't a complete solution, and I need to think more about 
using Capabilities in a standard XACML policy, but maybe this is a start.

Regards,
Anne

Rich Levinson wrote On 12/15/06 16:57,:
> Hi Anne,
> 
> I just want to mention that I think the profile is a great document
> and a really valuable example of how XACML can be applied.
> 
> I quickly looked over your suggestion and I think I must not have
> expressed my point clearly.
> 
> What I am thinking is that these XACMLAssertions,  both the
> XACMLAuthzAssertion and the XACMLPrivacyAssertions are
> elements that can be included in a ws:Policy elements and used
> in wsdl and other policy containers to express the requirements
> to clients as to what they need to do to successfully access the
> web service. I think we probably agree on that, and, if so, then
> I can get to what the issue is that I am considering.
> 
> I would expect (correct me if I am wrong, but this is what I am
> thinking) that it is perfectly reasonable, if not likely, that these
> XACMLAssertions will be part of an overall xacml architecture
> in various enterprise environments. As such, it is likely that
> there are one or mores PDP out there in the enterprise that are the
> home of a collection of xacml policies, as well as being the decision
> points handling PEP requests.
> 
> It is also my expectation that this PDP (or at least the people who
> adminster the PDP) will likely consider the Web Services to be
> Resources that its policies in general will cover.
> 
> So, I put myself in the position of one of these PDP admins and
> ask myself, how do I create a XACML Policy that will contain all
> the info I want to govern the access to this web service Resource
> (as suggested by the para 2 in section 4, etc.). What I am thinking
> is that only a subset of this info should go to the XACMLAssertions,
> which will end up in the wsdl, but the rest of the info I want to keep
> private and just use at runtime to validate and authorize requests and
> produce Responses etc.
> 
> So, the question is: how do I flag the subset of XACML Policy info
> that is targeted for the XACMLAssertions - I guess I am also assuming
> that the WebService Manager, in whatever form it will take, will in
> general make a XACMLRequest to the PDP to get the Policy or
> Policies governing this Resource. That Manager would then need to
> be able to select from the XACML Policy (as opposed to the WS Policy,
> which, on the other hand, the Manager is populating for setup etc.) the
> elements:
> 
>       <element ref="*xacml:Policy*" minOccurs="*0*" maxOccurs="*1*" />
>       <element ref="*xacml:PolicySet*" minOccurs="*0*" maxOccurs="*1*" />
>       <element ref="*xacml:Apply*" minOccurs="*0*" 
> maxOccurs="*unbounded*" />
>   <element ref="*xacml-context:Request*" minOccurs="*0*" maxOccurs="*1*" />
> 
> that can be moved from the xacml:Policy data to the Capabilities and 
> Resources
> elements of the XACML*Assertion.
> 
> So, I am wondering what the original xacml:Policy, which I assume can 
> contain
> the source elements for these XACML*Assertions, will look like and how one
> would go about selecting the appropriate info therefrom.
> 
> Bottom line is that the examples you suggested below, appear to me to be the
> final step of this process: i.e. some entity has put these ws:Policy 
> blocks as
> part of the wsdl or other that the client encounters before making the 
> actual
> access. To use your first example:
> 
>     <Requirements>
>        Has signed license agreement
>     </Requirements>
> 
> I would expect that somewhere in the PDP policy store that a xacml:Attribute
> might exist with an AttributeValue: "Has signed license agreement", and that
> when one queries the PDP for this xacml:Policy that they are able to 
> obtain this
> AttributeValue and put it in the Requirements element of the ws:Policy.
> 
> OK, so now hopefully that explains how I am looking at this and maybe there
> is some complete aspect to this that I am missing, that will help 
> explain it all.
> 
>        Thanks,
>        Rich
> 
> 
> 
> 
> Anne Anderson - Sun Microsystems wrote:
> 
>> Hi Rich,
>>
>> Thanks for the feedback.
>>
>> Rich Levinson wrote On 12/15/06 14:05,:
>>
>>>
>>>         61. WS-XACML: How are the contents of XACMLAuthzAssertions
>>>         represented in the base XACML Policies
>>>
>>> (Submitted by: *Rich*)
>>>
>>> Reading the spec, it appeared to me that an important piece of info 
>>> might be missing (or either I missed it or it intentionally is not 
>>> there, but that's the point of this issue). As an entry point to this 
>>> potential issue, consider statement in Section 4, p 23, para 2, that 
>>> says
>>>
>>> "For security reasons, many entities are unwilling to publish their 
>>> complete authorization and access control policies. Therefore, an 
>>> XACMLAuthzAssertion </xacml/AuthzAssertion> MAY not be a complete 
>>> specification of an entity's authorization and access control policy. 
>>> A service MAY choose to publish all or a subset of the 
>>> XACMLauthorization or access control policy it will apply with 
>>> respect to particular policy targets."
>>>
>>> How are the subsets of the core xacml policies identified as to what 
>>> should and should not be made public?
>>
>>
>>
>> It is completely site-dependent as to what is published and what 
>> isn't. Particular trade/service communities (on-line bookstores, etc.) 
>> might standardize policy vocabularies to be used in stating 
>> XACMLAuthzAssertions or XACMLPrivacyAssertions for their sites.
>>
>> As an example, Sun certainly isn't going to publish its enterprise 
>> policy.  But consider some fictitious software download site 
>> maintained by Sun; for this site, Sun might publish the following:
>>
>> <wsp:exactlyOne>
>>   <XACMLAuthzAssertion>
>>     <Requirements>
>>        Has signed license agreement
>>     </Requirements>
>>     <Capabilities>
>>        Provide trial version
>>     </Capabilities>
>>   </XACMLAuthzAssertion>
>>   <XACMLAuthzAssertion>
>>     <Requirements>
>>       Has signed license agreement
>>       Has paid for Level 3 support
>>     </Requirements>
>>     <Capabilities>
>>       Provide current production version
>>     </Capabilities>
>>   </XACMLAuthzAssertion>
>> </wsp:exactlyOne>
>>
>> Would it help to include an example like this?
>>
>> Also, it would be of interest to
>>
>>> see some example policies that contained entities that end up in the 
>>> Capabilities and Requirements sections of the Assertions. I am 
>>> particularly interested in how privacy requirements might be set up 
>>> in the original policy since these are generally not part of the 
>>> authorization process, per se', but possibly could be considered to 
>>> be modelled as XACML Obligations. Any guidance on this in reply to 
>>> issue or changes to doc would be much appreciated.
>>
>>
>> Consider a service policy saying the service will provide a copy of 
>> its current price list if the client agrees to retain it no longer 
>> than 30 days and not to disclose it to 3rd parties.  The service also 
>> says it will not disclose the client's personal information to 3rd 
>> parties.
>>
>>   <XACMLPrivacyAssertion>
>>     <Requirements>
>>        max-data-retention-days <= 30
>>        data-disclosure == "ours" }
>>     </Requirements>
>>     <Capabilities>
>>        resource-id="current-price-list"
>>        //p3p10full/POLICIES/POLICY/RECIPIENT/* subset-of { "ours" }
>>     </Capabilities>
>>   </XACMLPrivacyAssertion>
>>
>> A client policy might say:
>>
>>   <XACMLPrivacyAssertion>
>>     <Requirements>
>>        resource-id="current-price-list"
>>        //p3p10full/POLICIES/POLICY/RECIPIENT/* subset-of { "ours" }
>>     </Requirements>
>>     <Capabilities>
>>        max-data-retention-days <= 30
>>        data-disclosure == "ours" }
>>     </Capabilities>
>>   </XACMLPrivacyAssertion>
>>
>> There is another example using XACML's XML syntax in Section 6 of WD 8.
>>
>> Is this what you are looking for?  If you could describe ways in which 
>> the examples in Section 6 are inadequate, I could provide more 
>> examples or better examples.
>>
>>>
>>> Status: *OPEN*
>>>
>>

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