OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]