[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 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]