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
>
>
>>