[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] New Issue#61: WS-XACML: How are the contents ofXACMLAuthzAssertions represented in the base XACML Policies
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]