Re: [xacml] Comments on admin spec aka delegation profile

[Erik Rissanen <erik@axiomatics.com>]

Hi Rich,

Thanks a lot for the detailed review and comments! See responses inline.

Best regards, Erik

Rich Levinson wrote:
> Hi Erik,
>
> Based on discussion of 2.0->3.0 and use of the Categories
> in the admin spec, I have gone thru the admin spec and assembled
> the following comments. Most are typos and questions that I had
> reading the text that did not have obvious answers without looking
> at the whole thing and making deductions. However, I left those
> questions in the comments below to be considered as suggestions
> for clarifying the text for readers. Also there are a couple of
> items for the core spec. Finally, I rev'd v17 accidentally, but then
> checked and it appears v18 is simply the AnyOf, AllOf replacement
> so the line numbers did not change.

Yes, it's easy to miss the latest version. Since Anne left nobody is 
updating the web page. We need to find someone to do the updates.

> imo, the spec looks pretty solid, but I'd like to make sure that I
> understand things correctly. In fact, my overall suggestion is that
> section 4 be beefed up considerably with clear concepts that
> would be helpful reading the rest of the spec. As it is now, what
> I found was that it was very obscure and difficult to understand
> until I walked thru the example, which is very good, notwithstanding
> the comments that I made to it below.

Actually section 4 used to be longer, but I thought it was so obscure 
already, so I just gave up on it and made it shorter. As the text used 
to be, it used different terminology than the rest of the doc and tried 
to define the basic operations of the processing model in a couple of 
sentences. This just didn't work.

I suggest that we do not attempt to make a summary of the processing 
model. Instead we can rewrite section 4 to explain the basic principle 
that policy must be traced back to a trusted source, but don't try to 
explain any of the technical details here. It is understood better from 
the actual processing model, which itself is a just a few pages long 
anyway and the example.

Here is a proposal for an updated text for section four:

***
The purpose of the delegation model is to make it possible to express 
permissions about the right to issue policies and to verify issued 
policies against these permissions.

A policy may contain a <PolicyIssuer> element that describes the source 
of the policy. A special form of <PolicyIssuer> element, called the 
trusted issuer, is used to specify that a policy is trusted by the PDP. 
A missing <PolicyIssuer> element is shorthand for the trusted issuer.

A policy with the trusted issuer is considered trusted and valid and its 
origin is not verified by the PDP.

Policies which have an issuer different from the trusted issuer need to 
have their authority verified. The essence of the verification is that 
the issuer of the policy is checked against the trusted policies, 
directly or through other policies with non-trusted issuers. During this 
check the right of the issuer to issue a policy about the current access 
request is verified.

If the authority of the policy issuer can be traced back to the trusted 
policies, the policy is used by the PDP, otherwise it is discarded as an 
unauthorized policy. The authority of the issuer depends on which access 
situation the current access request applies to, so a policy can be both 
valid and invalid depending on the access request.

Steps in the validation process are performed using a special case XACML 
requests, called administrative requests, which contain information 
about the policy issuers and the access situation.
***

> Comments:
>
> comments on Delegation profile
>
> page 1: should it be called the
> XACML v3.0 Administration and Delegation Profile
>
> or something more descriptive of what it actually is than
> the current title, "Administrative Policy", indicates?

I don't know. Could someone who is a native English speaker comment on this?

> core spec line 2154 should this say "policy" instead of "policy set"?
>
> core spec line 1966, 1968 should <DisjuntiveMatch> be replaced w 
> <AnyOf> ?
> was probably missed by search and replace,
> core spec Suggestion: have parent AllOf in Target element rather than 
> implicit "conjunctive sequence"

The line numbers in the doc I am looking at seem to be completely off 
your numbers. Did you review wd 4? Could you say which sections the two 
comments above refer to?

> Should example in section 6 replace <Disjunctive... with AnyOf, etc.?

Yes, as you already noted at the top of your email, this is already done 
in wd 18.

> line 272 PolicySet needs policy-combining-algorithm moved up from line 
> 275-276,
> line 274 Policy needs rule-combining-algorithm

Yes, I am fixing these for the next version. I am also adding a PolicySetId.

> line 297 should there be a " " before "urn"? if so, then what about 
> lines 285, 309?
> also check other Policys for similar
No, there should not be a space there. This is caused by Word 
autocorrect which is not very fond of XACML and keeps braking it... 
Thanks for noticing. I also noticed missing quotes around a datatype xml 
attribute in policy 1.

> line 506-507 should this replace "subjects, resources, and actions"
> with something about categorys?

Yes, I am changing it to "The target with the standard attribute 
categories for the subject, resource and action constrain the situation 
that the policy applies to."

> line 508 "or rule" should be "or by rule" in order to avoid ambiguity
> as to what can contain targets.

Fixed.

> line 509-514: I don't understand the point. Line 509 says that Policy 1
> allows any situation which is an employee who prints on the printer.
> If they are already allowed, what is the point of granting the
> privilege to allow Carol to allow employees to print who are already
> allowed to print? (If the case is that an "administrative" policy
> does not actually grant the initial privilege, please state that
> explicitly, so as to give this use case some substantive meaning)

I changed this to "In this case the policy allows granting policies 
about any situation which is an employee who prints on the printer."

> line 91-103: on first and second readings, I did not "get" from this
> that the presence of a "delegated" category implies the policy is
> "administrative" as implied by the example text on line 510-511.
> line 83-84: further confusion on what characterizes admin vs access
> policys since this says "possible to write a policy which matches
> both types of request".

I prose that we throw away lines 91-103 and 83-84, as I suggested above 
considering section 4.

> line 558: refers to section 5.2.6, which is not in this doc

I am removing this reference. It was a remnant from an older version of 
the doc. It used to refer to the processing model as it was before we 
generalized the attribute categories. Section 5.2.6 contained a number 
of special case matching rules to work around the lack of generalized 
categories. With the general categories this is not needed anymore and 
the target matching is given by the normal XACML 3.0 model.

> line 561: should the PolicySet be considered "trusted" because there
> issuer? Also might want to mention this on line 506 as well.

Yes, the policy set is trusted since there is no issuer. However, the 
policy/policy set where the PDP start evaluation is a special case 
because if the policy set/policy would have an issuer, then there would 
be no way to reduce it anyway since it has no neighboring policies.

This is an old issue in the issues list and we decided to ignore this 
problem, and the result of the evaluation is returned as it is 
regardless the trustfulness of the initial policy set/policy. In other 
words, it is implicitly assumed that the top level policy is always trusted.

See issue 27 in the issues list:

http://wiki.oasis-open.org/xacml/ClosedIssues

> line 564: why do we want to consider the question of whether there
> is an "edge" between policy 4 and policy 2

We need to consider whether there are any edges between policy 4 and any 
other policy in the policy set. The example starts with policy 2 just 
for simplicity in the presentation, since we know that there will be an 
edge in this case. I am reformulating the text like this:

"Policy 3 and Policy 4 need to be reduced since they are not trusted. We 
begin by creating the reduction graph. Creating the reduction graph 
means finding any edges between the policies in the policy set. We need 
to check each pair of policies for an edge (although in pracictice a PDP 
may optimize the search to find a minimum set of edges as needed to 
determine the result). First, consider the question whether there is any 
edge between Policy 4 and Policy 2:"

> line 569: why would an admin req to policy 2 answer the above question?

This is because of the definition of an edge from the processing model 
spec. There is an edge if and only if the admin request evaluates to 
permit or indeterminate. I have updated the text:

"As defined by the processing model, there is an edge if and only if the 
administrative request generated from policy 4 evalutes to Permit (or 
Indeterminate) for policy 2. So to test for an edge, we create the 
following administrative request, and evaluate it against Policy 2:"

> line 624: please mention that "Bob" is the issuer of policy 4 here.
Done!

> line 505,556,622: please label these listings as Listing 1,2,3 or other
> referencable identifier.
Done!

>
> line 624-625: please state that the subject, resource, and action from
> "listing 2", the original request are copied to "listing 3" the admin
> request, and the subject, resource and action categories are transformed
> to "delegated".
>
> line 607-611: I understand that above this, Bob, is copied from policy 4
> in listing 1, however, I do not understand why this "administrator"
> element has been added. Lines 628-629 say that the CH did this, but
> how would the CH know it needed to do this and how would it know
> Bob was in the administrators group?

The context handler provides all available attributes in the 
<Attributes> elements of the request. This is the job of the context 
handler. It is an abstract architectural concept, so there is no 
detailed specification for how to do it in practice. It would depend on 
the implementation and environment.

For instance, the context handler could know that the subject-id 
attribute can be used to look up more attributes from an LDAP accessible 
directory. The administrators group could be found there. But these 
details are out of scope in this document. There is a note on the 
context handler in section 5.5.

What you are really asking for is a standardized context context handler 
specification, which is really the same question you have been asking 
many times in the context of the core spec, that is missing attributes, 
etc. Such a spec might be interesting to do for common setups, such as 
SOAP based webservices and federated attributes based on WS-* and/or 
SAML. But it doesn't belong in the delegation spec.

To clarify, I added the following text:

"(The details of how the context handler found the administrator 
attribute depend on the PDP implementation and the available attribute 
sources in the particular implementation.)"

> line 633-635: Since policy 2 is permit-overrides, why would one generate
> a Deny request here, since we already got a "permit"?

The particular combining algorithm does not matter. It has to do with 
the definition of the reduction graph. By the definition, the edge 
exists in the graph so I included it in the example. I tried to make the 
example as close as possible to the definition of the processing model, 
not performing any optimizations for instance.

However, since policy 4 evaluated to Permit, we are not really 
interested in the DP edge since we are looking for only PP edges. So a 
PDP can optimize in this case and skip this administrative request. I 
have added the following note to clarify this:

"Also note that since policy 4 evaluated to “Permit”, the DP edge is not 
really needed, although it is specified in the definition of the graph, 
so this request could be skipped by an optimizing PDP."

>
> line 638: I understand that policy 2 is not trusted so we keep going, but
> why did we not first try to go direct from policy 4 to policy 1? If this
> would have worked, why bother with policy 2? Oh, because policy 4 was
> issued by Bob? So, that above we have to look for policies where Bob 
> is the "delegate"?

Yes, by the definition of the graph, we would try to go directly to 
policy 1, but since I know that it won't lead to a valid path (because 
Bob is the issuer, and Bob is not allowed by policy 1), I wrote the 
example walkthrough in this order. At the end of the walkthrough I say 
that in this case there are no more edges and we have the full graph, so 
this covers the case of going from 4 to 1.

> If that's the case, then why do we talk about the "reduction graph" on
> line 564? Don't we just run the listing 3 admin request and it finds that
> Bob is the delegate of policy 2 automatically? I think the graphs just
> confuse things. They may be useful for referencing what is happening
> automatically, but the text makes it seem like they are some kind of
> construct that one needs to build into the PDP?

The delegation model is defined in terms of the graph. It will be 
necessary for a PDP to build the graph, but an optimizing PDP will in 
many cases be able to find a definite result without building the whole 
graph as defined by the formal specification. I wrote the example as 
close to the specification as possible, rather than as an example of an 
efficient PDP. The PDP could conceivably do very clever things, which 
would confuse someone just trying to understand the basic model. To 
clarify this, I have added the following text at the beginning of the 
example:

"As specified in the processing model, reduction consists of two steps. 
First a reduction graph is built, and then the PDP searches the graph 
for a path to the trusted policies for each policy with an issuer 
different from the trusted issuer. Note that this example follows the 
definition of the processing model and does not attempt to be efficient. 
An efficient PDP can mix edge creation and path searching so that only 
those edges which are actually needed are created. This example does not 
do so for simplicity. We create a full graph before we do a search."

> line 692: listing 4

Done.

> line 693: here it would useful to say that since Carol is the issuer of
> policy 2, that here she is the requesting "delegate" of listing 4.
> How come Carol doesn't get an administrator group or something else
> like Bob did?

It just happens that Carol is not in the administrator group. The 
context handler again. I added a note about this in the text.

> line 694: again, why a subsequent Deny when we are operating under 
> permit-overrides?

Again, this is for building the full reduction graph.

>
> line 707: what if the PolicySet is not trusted, i.e. what if it had
> an issuer like "Carol"? Do we have to go all the way up the tree?
> i.e. can untrusted issuers create PolicySets that contain trusted
> Policys with which they could possibly override other protections?

I wrote about this above in this email. As I wrote, we discussed this in 
the past and we decided to just ignore this issue and let it be 
implementation specific. Presumably no-one would run the PDP with an 
non-trusted policy as the initial policy.