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

[Rich Levinson <rich.levinson@oracle.com>]

Hi Erik,

I am just starting to go thru your comments, but fyi, the core version
I am looking at is xacml-3.0-core-spec-wd-04-en.doc from
the wd4 zip file. The sections are 5.13 <Policy> the one line expl of
PolicyIssuer. Since this is under the Policy section, why
does it say "policy set" and not "policy"? 1966, 1968 are in
5.5 <Target>.

    Thanks,
    Rich

Erik Rissanen wrote:
> 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.
>
>