[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 Martin, I think a "cross-walk" would be helpful. Can we get scheduling such a joint discussion on the agenda for tomorrow? Could we invite the SOA-RM people to an XACML TC meeting in the near future? Regards, Anne Smith, Martin wrote On 12/20/06 13:23,: > The OASIS SOA-RM (Reference Model) has a concept called "service description"; another called "policy" and another called "contract." In general, "service description" is visible; "policy" is "owned" by a service and is probably not completely visible (or maybe the visible part is published into the "service description".) Contract is owned jointly by the participants in a transaction--presumably visible to them but probably not typically to others. > > At the level of abstraction of the RM, nothing is said about policy language or contract representation, and the details of what's in service description ("metadata") are TBD. > > All these areas might address some access-control policy issues, but of course they would include other issues as well--pricing, service levels, usage instructions, etc. > > At some point, it might be good to do a cross-walk between the SOA-RM (and Reference Architecture, forthcoming) and XACML work (and SAML work while we're at it.) That might result in some "fit" that would give you logical slots for "WS-XACML." > > (OASIS SOA-RM TC home page: http://www.oasis-open.org/apps/org/workgroup/soa-rm/index.php > and on policy specifically: http://wiki.oasis-open.org/soa-rm/TheArchitecture/Policy ) > > Martin > > > Martin F. Smith > Program Manager, Information Sharing & Identity Management > DHS CIO Office > 202 447-3743 (New! as of 10/2006) > 202 441-9731 cell > > > ________________________________ > > From: xacml-return-119-martin.smith=dhs.gov@lists.oasis-open.org on behalf of Anne Anderson - Sun Microsystems > Sent: Wed 12/20/2006 9:23 AM > To: Rich Levinson > Cc: xacml@lists.oasis-open.org > Subject: Re: [xacml] New Issue#61: WS-XACML: How are the contents of XACMLAuthzAssertions represented in the base XACML Policies > > > > Hi Rich, > > The problem to me with having WS-XACML policies integrated with other > policies is that it is not possible in general to extract an isolated > <Apply> statement from a normal policy - that <Apply> might be in the > middle of an "...:and" function, for example, that requires it to be > associated with other constraints. Or it might be in an "...:or" such > that it is not necessarily required to be true. > > That was why I suggested that WS-XACML policies be contained in a > top-level separate PolicySet. The policies in that set can be "AND"ed > with the remaining policies using an appropriate combining algorithm. > Then during evaluation of the remaining policies, if you know the > WS-XACML policies have already evaluated to "true", then you don't have > to re-evaluate the WS-XACML PolicySet. > > <PolicySet PolicySetId="all:policies" > PolicyCombiningAlg="ordered-deny-overrides"> > > > <PolicySet PolicySetId="ws-xacml:policies" > PolicyCombiningAlg="deny-overrides"> > > <!-- These don't have to be re-evaluated if you know they > must have been satisfied in order to get this far --> > > ... WS-XACML Assertion Requirements, > written as <Policy> elements ... > > </PolicySet> > > <PolicySet PolicySetId="other:policies" > PolicyCombiningAlg="deny-overrides"> > > ... Remaining policies, which can assume > the WS-XACML Assertions have already > evaluated to "true"/"permit" ... > > </PolicySet> > </PolicySet> > > Another idea is to use the WS-XACML policy constraints to partially > evaluate the remaining policies. For example, if you know that a > WS-XACML policy requiring "role" to be a subset of {"manager", > "auditor"} must evaluate to "true" before other policies are evaluated, > then you can go through the remaining policies and replace any > predicates that require "role" to be a subset of {"manager", "auditor"} > with "True". But I don't think it is worthwhile pursuing this: when > there are multiple WS-XACML policy alternatives, you don't know which > one will be the one that evaluated to "True", the cost of determining > the intersections with every predicate in the other policies is high, > and in many cases the intersections can't be fully evaluated (e.g. a > predicate that says "role" must be a subset of {"manager", "individual > contributor"}). > > I misspoke yesterday when I said the Capabilities could be included in > the overall XACML policies as "or"ed constraints. The "Capabilities" > are things the issuer of a policy is willing and able to do for the > other party and, as such, play the role of an XACML Request to the other > party, and not an XACML Policy that the other party must satisfy. So > above I said to write the only the Requirements as Policy elements in > the WS-XACML PolicySet. > > Regards, > Anne > > Rich Levinson wrote On 12/19/06 19:46,: > >>Hi Anne, >> >>I guess I have not been thinking along the lines of "WS-XACML" policies >>as being a distinct class of xacml Policy, but that the info in this >>profile would >>be worked into existing xacml Policy structures, but maybe the analysis >>below might be interpreted from either perspective. >> >>Basically, the point of view I am looking at this from is that I see >>that web >>service access is now effectively a 2 step process, whereas before >>WS-Policy >>was introduced, it was essentially a 1 step process where one just >>submitted one's >>request, for example using WS-Security, and hoped for the best. >> >>It is clear the 2 step process has the advantage that in step 1, the >>client is >>now formally told in advance, what the reqts are to successfully submit >>the request. Then, in step 2, based on the input from step 1, the client >>can construct a request that should be in compliance with the policy >>requirements that will be applied by service infrastructure when the >>request is submitted. >> >>So, from my view, step 2 doesn't change that much from what currently >>exists today (except for new features such as the privacy obligations >>that are currently being included in this profile - I think the >>"Capabilities" >>are also new, but I see them more relevant in step 1 than step 2 - i.e. >>if the client doesn't like the service capabilities, then it probably never >>gets to step 2). >> >>Bottom line is that my expectation is that many XACMLAuthzAssertions that >>are supplied to the client will, in general, reflect aspects of existing >>policies >>that are in current operation. For example, maybe a service requires >>that a client >>submit a valid "gold club member number" in some element of the request >>and this >>element is evaluated as part of authorization. >> >>Now, in order to make the service more readily accessible by users, the >>service >>provider decides to put a XACMLAuthzAssertion in the WSDL that will specify >>this constraint. >> >>If you agree that the above is a possible or typical az type of >>scenario, ..., >>then it appears to me the next logical concern is that: somehow, in the >>Policy >>that contains the "gold card member number" constraint, a "flag" of some >>sort would be appropriate to apply to that constraint in order that a >>service >>provider would know by reading the Policy for that resource (presumably >>thru some TBD policy access/distribution mechanism). Possibly the >>constraint >>could be a VariableDefinition that could be referenced in the main az >>policy >>and a separate Policy segment for use in constructing XACMLAuthzAssertions. >> >>My sense is that something would be useful in the WS-XACML profile that >>would advise on how to construct new policies and adapt existing policies >>to address this issue (i.e. issue 61). >> >>I think the profile identifies 3 major classes of info: >> >> Requirements of the az type - i.e. constraints that are typically >> found in existing policies. >> >> Requirements of the privacy type - i.e. constraints that bind the >>user as >> to how the resource is used once acquired (these may be considered >> just another az type in general, but they are "new" in the sense >>that >> they are things the user has to "agree to" and as such the user >>needs >> to know what is being agreed to, and how in the request to represent >> the fact that the agreement is accepted). As such these reqts >> may lend themselves to be separable off in a separate Policy or >> PolicySet. >> >> Capabilities in general - the service is simply adding info to be >>presented >> to users indicating things the service is willing to commit to, >>and as such >> would seem to be properly considered part of the Policy governing >>the >> publication and use of this service by the Provider organization. >> >>Another path that might make sense would be to model these XACMLAssertions >>as xacml:Obligations, whereby the "obligation" would be to inform the user >>of this Policy info, which could be presented directly thru PEP access, >>if, for >>example, the request was denied because something was missing that might >>be in this category of info (i.e. this would allow the info to provided >>either >>in advance via WS-Policy or on the spot in a "1-step" manner). >> >>I think the above or parts of it might be considered guidelines for a >>possible >>proposal and explanatory context for what might be considered to be added >>to the profile, but it probably needs to be shaken out a bit, assuming that >>you and/or others think it's valid subject matter for this profile. >> >>Also, I think it is possibly in synch with your proposal. i.e. it looks >>to me like we are >>generally on the same path - ex. where you pointed out section 3.2 for >>containing >>Apply elements, I was considering those to be the az-type requirements, >>and your >>site-specific naming convention looks like it might be similar to the >>"flag" I suggested >>to apply to items in existing policies. >> >> Thanks, >> Rich >> >>Anne Anderson - Sun Microsystems wrote: >> >> >>>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 > > -- 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]