[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 XACMLAuthzAssertionsrepresented in the base XACML Policies
|
Hi Anne, I want to get back on the discussion we had in the F2F on issue 61. I have attached below a cobbled together set from the earlier emails, which removes some of the indentation to make the previous messages easier to read since there is a lot of useful context there. (Note: unfortunately, I had to dial in to the F2F and the communication was not easy, but we did the best we could under the circumstances.) In any event, based on your proposal for issue 61, it appears to me that what you are suggesting is that the XACMLAuthzAssertions can be "flagged" in a domain specific manner, and contained in separate policies (see email below: Tue, 19 Dec 2006 10:45:36 -0500). This would be an administrative responsibility to set these up according to the needs of the organization. Then, the web services manager would issue a query using the SAML 20 Profile, which would identify the policies using the domain-specific indicators, which would enable the web services manager to collect all the XACMLAuthzAssertions and apply them to the local wsdl as necessary. If this is correct then I think things can probably be made to be workable with some further analysis along the lines of the policy combining etc that would occur at runtime when the resource was actually accessed. So, I guess the key point that I had been missing was the concept of flagging and querying for the policies, although in retrospect, looking over the emails it probably should have been more clear. I guess my assumption was that one would need to actually query by resource to find the associated policies and what I was missing was the out of band setting up of the web services manager to know what policies to request explicitly. Let me know if this sounds like we are on the same page. Thanks, Rich -------- Original Message --------
Anne --
Hmm . . . I see my "conflict" issue was dangerously close to be a stupid comment. <g> On the bright side, that's one fewer thing to worry about.
You and Hal refer to a situation where a rule would never have effect, e.g.,
<Policy ruleCombiningAlg="deny-overrides">
<Rule A: Group X is Permitted access to resource Y/>
<Rule B: Group X is Denied access to resource Y/>
</Policy>
where the variables to the left and right are identical, but the operation is contradictory. Hal says
> A tool to
> detect this kind of thing could be developed, but many feel it would
> have little value as this thing is easy for a person to spot and few
> policies are written this way.
>
At this point I'd say it would be nice to have such a tool, because I'm guessing the rule sets could become large enough to make such a situation non-obvious. But I don't have operational experince to back that up, and as he says, it's a tools issue.
If there existed a reference ontology that defined permanent logical relationships ("Banana IsA Fruit"), then the scope for spotting definite inconsistencies would be greater--
<Policy ruleCombiningAlg="deny-overrides">
<Rule A: Banana is Permitted access to resource Y/>
<Rule B: Fruit is Denied access to resource Y/>
</Policy>
But clearly we aren't anywhere near having such a semantic reference.
As you both point out, in the more common case you can't tell that a rule won't have effect without reference to the actual values present in the attributes of the relevant sets of resources and requestors. It would be very handy to have a tool that would map the effect of a rule against those data (or a sample thereof) : adding rule x would change access to resource y for requestors with characteristics 1, 2 and 3 but not 4, which, by the way, is 1,234 requestors. It would even be handy to have a "test" service that would accept a user ID and target resource and return an access decision with "explanation" (what rules and attribute values determined the decision.)
I guess these are tools issues, not something that needs to be in the standard. In fact I suppose they may already be out there and I just don't know about it.
Thanks again to you both for the clear explanation.
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 [mailto:Anne.Anderson@sun.com]
Sent: Thu 12/21/2006 11:38 AM
To: Hal Lockhart
Cc: Smith, Martin; Anthony Nadalin; Rich Levinson; 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
Here is another common example of difficulty in determining
"conflicting" rules. Consider the following Policy:
<Policy ruleCombiningAlg="deny-overrides">
<Rule A: Group X is Permitted access to resource Y/>
<Rule B: Anne is Denied access to resource Y/>
</Policy>
If Anne is a member of Group X, these "conflict" in that Anne is
permitted access according to Rule A, but is denied access according to
Rule B. But in most cases, this type of "conflict" is just a typical
use case for "deny" rules: write a general Permit rule that covers most
cases (Rule A), but then handle exceptions with Deny rules (Rule B).
Note that if only "Permit" rules or only "Deny" rules are used, there
will never be "conflicts", just possible overlaps.
As Hal points out, the combining algorithms handle every such "conflict"
according to the direction of the policy writer, so no analysis tool can
tell whether they are intentional or not. Even the case of two
identical Rules, with identical effective Targets and chains of
combining algorithms (computed using all encompassing Policy and
PolicySet elements), with one returning "Permit" and the other returning
"Deny", is not necessarily a "conflict", since they must be considered
in the context of other Rules in their respective encompassing Policies.
The use of PolicySets, each covering some specific area of concern,
allows groups of Rules and Policies to be managed by the people who are
responsible for that area. They can be responsible for ensuring that
"their" PolicySet correctly reflects their intentions. They can also
raise a concern if they feel "their" PolicySet is being incorrectly
combined with other PolicySets at higher levels. The XACML 3.0
Administrative Policy allows an organization to control who can specify
policies that affect some particular area of concern.
Regards,
Anne
Hal Lockhart wrote:
> The features of XACML 2.0 perfectly match these requirements. The use of
> policies and policy sets along with policy combining algorithms allows
> policies that address different concerns (privacy, application
> structure, regulatory requirements), or different scopes (department,
> division, organization) to be created by distinct administrators who are
> not closely coordinating their activities. The processing rules of XACML
> will automatically collect all the policies relevant to a given
> situation and the combining rules will resolve any conflicts.
>
> In past, we have had debates as to whether or not there is such a thing
> as a policy consistency check. At a minimum there are numerous
> difficulties with determining if a set of policies "conflict" in the
> intuitive sense of the word, except in the most simple and obvious
> cases.
>
> Of course if I have a policy with two rules, one of which says if
> subject is a member of the foo group, permit and another which says if
> subject is a member of the foo group, deny, intuitively we would say
> this is probably not how the policy was intended to be written. However,
> XACML has no problem evaluating such a policy and giving a deterministic
> answer (which depends on the combining algorithm in force). A tool to
> detect this kind of thing could be developed, but many feel it would
> have little value as this thing is easy for a person to spot and few
> policies are written this way.
>
> Now consider a more realistic example. Suppose one policy says members
> of the foo group can access resources with the bar attribute value
> greater than 100 and another policy says that members of the blah group
> are not allowed to access resources with a splat attribute value of less
> than 1000. Are these conflicting? The answer depends on the assignment
> of attributes to subjects and resources. It also may depend on the
> particular access request. Further, the attribute assignments may not be
> known at the time of policy creation. In fact, the assignments my change
> over the lifetime of the policies so that at one point in time they
> always conflict and at other time the never conflict and perhaps at a
> third time they conflict for some requests and not for others.
>
> Hal
>
>
>>-----Original Message-----
>>From: Smith, Martin [mailto:Martin.Smith@DHS.GOV]
>>Sent: Wednesday, December 20, 2006 4:59 PM
>>To: Anne.Anderson@sun.com; Anthony Nadalin
>>Cc: Rich Levinson; 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
>>
>>Anne --
>>
>>For what it's worth, in my organization we have been viewing privacy
>
> rules
>
>>as just one of several sets of rules controlling access (to data
>
> assets.)
>
>>We envisioned each set of rules as being managed by a separate
>
> authority
>
>>(e.g., Chief Privacy Officer for privacy rules based on the Privacy
>
> Act)
>
>>using some tooling interface of the PAP and being applied jointly in
>
> the
>
>>access-control PDP.
>>
>>This implies a potentally large set of rules, which may raise some
>>engineering issues (lots more cycles determining access than in
>
> executing
>
>>query.)
>>
>>It also suggests the need for a "consistency check" (in the PAP?) to
>
> make
>
>>sure rules don't contradict each other. (For extra value-added, create
>
> a
>
>>"rules inconsistency resolution" service to facilitate among rules
>>authorities.)
>>
>>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-125-martin.smith=dhs.gov@lists.oasis-open.org on
>
> behalf
>
>>of Anne Anderson - Sun Microsystems
>>Sent: Wed 12/20/2006 3:30 PM
>>To: Anthony Nadalin
>>Cc: Rich Levinson; 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
>>
>>
-------- Original Message --------
Anthony Nadalin wrote On 12/20/06 10:12,: > One thing that bothers me (well I have several), > > 1) is why is this called WS ? as I'm not seeing a tie to web services, > just to WS-Policy XACMLAssertions were originally designed as a way to include XACML policies in WS-Policy instances, and thus tie XACML more directly to Web services, but the XACMLAssertions are certainly useful for more than WS-Policy. WS-Authorization and WS-Privacy have been mentioned numerous times, although I have not seen anything moving forward, and it seems to me that the XACMLAuthzAssertion and the XACMLPrivacyAssertion should be able to fill the roles possibly envisioned for those two specifications. The other two parts of the WS-XACML specification - the authorization token and passing Attributes in the SOAP header - are more explicitly Web services oriented. That said, the XACMLAssertions are useful both in WS-Policy and in other contexts. I have proposed dropping the non-Assertion sections from WS-XACML, and if so, I would be open to changing the name to something like "XACML Authorization and Privacy Policy Assertions" (XAPPA? :-) > 2) missing the tie to WS-Security, as SAML is not the only assertions > that are used, this effort should be able to tie into the claims used in > WS-Security Are you referring to ways an XACMLAssertion could refer to WS-Security claims used in the SOAP Security Header? I could define a new standard vocabulary identifier for such claims, and could give an example of placing constraints on them. Do you want to supply an example of a claim you would like to see used? > 3) there are 2 sides the requestor and receiver, each should be able to > represent policy, not seeing this clearly in this proposal Section 6 of WD 8 shows a client XACMLPrivacyAssertion and a Service XACMLPrivacyAssertion. What more would you like to see? The academic team I am working with has made use of XACMLAssertions in a multi-stage privacy policy negotiation protocol, so once our paper is finished, perhaps I could include that as an example that would show the two sides even more clearly. Thanks for the review and comments. Regards, Anne > > Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 > Inactive hide details for Anne Anderson - Sun Microsystems > <Anne.Anderson@sun.com>Anne Anderson - Sun Microsystems > <Anne.Anderson@sun.com> > -------- Original Message --------
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,: -------- Original Message --------
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
>
-------- Original Message --------
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]