[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 --
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
>>
>>
>>
>>
>>
>>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>
>>>
>>>
>>> *Anne Anderson - Sun Microsystems
>>> <Anne.Anderson@sun.com>*
>>>
>>> 12/20/2006 08:23 AM
>>> Please respond to
>>> Anne.Anderson@sun.com
>>>
>>>
>>>
>>>To
>>>
>>>Rich Levinson <rich.levinson@oracle.com>
>>>
>>>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
>>
>
>
--
Anne H. Anderson Anne.Anderson@sun.com
Sun Microsystems Labs 1-781-442-0928
Burlington, MA USA
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]