[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Comments on admin spec aka delegation profile
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]