[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 of XACMLAuthzAssertions represented in the base XACML Policies
Anne --
I am just an "observer" in the SOA-RM TC. Which is why I cc'd Frank McCabe, who is Secretary of the TC. I think he might be the right person with whom make TC-2-TC arrangements.
I will be happy to assist as I'm able.
Thanks,
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: Anne Anderson - Sun Microsystems [mailto:Anne.Anderson@sun.com]
Sent: Wed 12/20/2006 3:11 PM
To: Smith, Martin
Cc: xacml@lists.oasis-open.org; frankmccabe@mac.com
Subject: Re: [xacml] New Issue#61: WS-XACML: How are the contents of XACMLAuthzAssertions 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]