[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] input for policy subcommittee telecon dec. 3
Dear colleagues, below are some comments on the draft v.7 that Tim circulated inserting the policy committee working document into the complete saml document. Also below are some comments on the comments that have already been circulated on v.7. I'd like to go over all this (and then to other comments i might have missed or that any of you might have) together with you at the concall tonight to reach a consensus of the subcommittee of the different issues that we have brought up for discussions. for many points i think discussing by voice at the concall is better than having back and forth by email. I hope we will be able to discuss all the matters in a constructive way (as it was the case for many of the pleasant and productive concalls we have had in the past) talk to you later best -p P.S. no need to read all this before the concall (which will be in three hours, but it would be nice if you could have this and the exchanged msgs handy) ================ Comments on the draft========================= page 3,line 62: applicable policy. As it is stated it seems to assume an indicization w.r.t. the resource, which i think it was nevert page 3,line 68 : "classification", is this the set of attributes associated with objects (equivalent to SAML assertions for principals) page 3, line 69: notion of context not clear. page 3, line 75: about the definition of policy. I believe that it was agreed to term as "policy" a set of access control rules. Why is policy pointing to applicable policy? page 3, line 78: Definition of PDP not clear to me. Is it intended to mean that the PCP determines which rule constitute the applicable policy w.r.t. a request page 4, lin1 84: what does it mean for the applicable policy to be complete? shouldn't PRP be defined as the entity that retrieves all the rule applicable to a given request (note request, not resource) page 4, line 92: about the definition of principal. Shouldn't it be explicitely defined as the "entity requesting access"? The definition at line 92 could match anything (even a resource) page 4, line 94: definition of role. I believe we discussed this in a couple of telecon and this was not the definition i recall. Why would we need the definition of role this way? page 4, line 95: definition of rule. I remember again a discussion at a telecon (Nov. 19) where participants agreed that they did not agreed on the definition of rule. It was said we should have talked with Tim (Moses) about this but at the last telecon there was no possibility of any discussion. page 4, line 100. I do not believe the term attribute is used in places of privilege, permission, right, and authorization. page 4, line 102: the terms subject and user although often used as synonims if the terminology is clarified beforehand are a different concept. It is not clear whether with this sentence we want to mean that principal is used in place of user. page 4,line 106. Role vs group (this is an open matter for discussion i believe). Also w.r.t. the definition given for roles (line 95) page 5, line 137: "PRP returns the policy" shouldn't it be the *applicable* policy? or are all the rules passed along? page 5, lines 138-141: related also to the previous point. The applicable policy should depend on the evaluation of conditions on the attributes, are rules for which conditions cannot be evaluated considered part of the policy that is passed along? page 5, line 146: "policy instance", i do not think it has been defined. page 5, line 148: "if the policy were to evaluate to TRUE" there seems to be a gap here as it is not defined when a policy evaluates to TRUE. I do not comment on post-conditions as the discussion is still open. page 13, lines 334-335: not completely clear. Also, it is not clear how the discussion in this paragraph relates to the notion of role as given in the glossary. Role was defined in the glossary as a set of attributes (although i do not think this is the definition we have assumed in the policy committee telecons), line 335 state "role may have attributes. ???? page 14, line 355: classification can have attributes? wasn't it defined as set of attributes? Can a resource have different classifications (each stating a set of attributes)? from the glossary and the examples it is not clear what we are assuming. Classification seems also to be used to denote groups (line 386-387: "resource ... belongs to the classification") page 15, line 396. "each rule is composed of a pre-condition and zero or more post-conditions page 5, lines 395-400. seems ok but it is a generic statement that i think we will need to investigate more. ===================== end comments on the document ================= ==================== responses to earlier postings ================= (in order of date and stating the sender, my comments are indented) TIM MOSES: Line 163 - Policies will commonly evaluate attributes of a principal, or set of principals, not merely its identity. there is no statement about identity, the principal expression is a boolean expression over principal's attributes Line 165 - Allowing dynamic actions seems unnecessarily complicated. these are not dynamic actions are expressions over action. ok, if we want to have an explicit action stated. What that line was meant to state (probably is was not stated well) was that like for principals and resources, the actions on which a rule applies are stated as expressions. I think these feature was useful to express conditions on action's parametes. Some example of conditions we may want to have on action parameters are also constraints on the recipients of some data was (see Fred example) that policies are identified with the resource action and resource classification, meaning that this information is contained in the policy instance, and used to identify the policy, for purposes of locating, retrieving and verifying it. This solution is impacted if actions are dynamic. well reading the first part of the draft and the glossary it seems you index on the resource rather than on the action. In any case even for the resource we have this problem then (and i believe in previous concall we were working under the assumption that a rule is *not specified for a single resource* but for a set of them (those that match the resource expression) Line 168 - PDPs may also execute some post-conditions. post-conditions were not clear in the draft as they have not been discussed yet Lines 179-181 - Figure 2 accommodates this requirement by identifying separate types for role, classification and environment attributes. not clear what you mean by this, we can clarify at the concall tonight Section 3.2.3 - Figure two provides a solution without differentiating between expressions for principals, resources and environment. Some policies will require comparison between attributes of principals and attributes of resources. So, separating expressions for principals from expressions for resources does not seem helpful. it is true that you can see everything as a single combined expression. Seeing them separate was for clarity. It is true that some expression will need to evaluate attributes of principal and reources in relationships (e.g., the example we have mentioned few time about a rule stating that ``users can access the object for which it is owner''). in the assumption we were making the principal expression would contain only conditions on principal atrtributes while the relationship between the resource attribute and the principal is stated in the resource expression. In any case seeing them as a single complex expression or separated does not make much difference w.r.t. expressiveness. Line 187 - Contains a new definition for "role", vis "privileged position". postponed to the discussion on roles we are having Section 3.2.5 - It is better to make the parameters attributes of the resource, not the action. Otherwise, a different solution for binding policy to the saml authorization query must be devised. In the example given, the resource can be the "withdrawal", with attribute "500,000", then the action can be "withdraw". The policy can then be bound to the resource "withdrawal" and the action "approve". not clear. how do you translate parameters of the action to parameters of the resource? Line 243 and on - According to the explanation of Figure 2, rules must be logically combined in policy. They are not merely "listed". This removes any ambiguity about combining rules. what do you mean by ``logically'' combined? logically combined means taking the OR of the rules, the discussion claims that that is not enough. The distinction about restrictions and authorizations (which is still at the preliminary discussion was to avoid negative authorizations, see discussion we had about negative authorizations) Line 300 - Dynamic conditions are accommodated in the model using "external functions". postponed again, better discussed by voice. Line 301 - Post conditions are accommodated in the model. postponed again, better discussed by voice. Line 302 - Content "introspection" is accommodated in the model for both XML documents and non-XML documents. In the former case, the resource attribute contains an XPath expression into a document of the specified type, it being implied that the instance referred to is the one identified by the saml authorization query. In the latter case, the resource attribute contains an XPath expression into a saml attribute assertion, probably issued by the PEP and containing attributes of, or values from, the resource. i am not completely sure about this, postponed again, better discussed by voice. Line 313 - This is dealt with in Figure 9. discuss in telecon ================================================================ HAL LOCKHART First of all, I have already conceded that we probably need negative rules, so lets not argue about that. i think we are still discussing whether to have negative authorizations or not. When i first mentioned negative authorizations you had a very strong reaction and responded ``Anybody who has worked in operational security for any period will tell you that negative controls should be avoided like the plague.'' as i said i that time i did not agree with your statement. i do agree however on the fact that negative authorizations do definitely bring complications. One thing that concerns me about your example is that it is a completely different problem space from any of our use cases. Now I am not trying to disqualify it on a technicality, but I do have a concern that it may represent a problem that is outside of the scope of XACML. Someone (not me of course) might argue that filtering emails is more like doing a text search or a database query than creating a policy model. Can you recast the example in one of the use case problem domains, such as medical records or XML documents? Alternatively, would you like to submit a usecase around filtering SPAM? Bill examples were referring to email filtering but you can imagine similar examples to block access to your resources (e.g., for the .htaccess file you specify to protect web pages) This seems problematic to me, particularly in situations where policies relating to a particular access request are generated by several individials independently. But I have not read her paper completely or thought about it carefully. again it was an attempt to avoid negative authorizations for which it seemed there was strong feelings against. We can (i hope) discuss this better in the telecon. ================================================= HAL LOCKHART The general problem being discussed is that many existing accesss control systems imbue certain attributes with special semantics. In contrast, X.509 and SAML, for example, consider that attributes are just name value pairs and special semantics are up to the implementation. Examples of special semantics include: clearances, nested roles and dynamic roles. I feel compelled to point out, in passing, that the the hierachy represented by clearances and the hierarchy represented by nested roles (groups) are completely different from each other. agreed. i believe that the hierarchies Simon (Godik) has been referrin to in our concalls where simply the groups and roles hierarchies (we have never been talking about multilevel access control) ============================================================ HAL LOCKHART We need to decide as a matter of terminology, whether the decision to allow or prohibit access is considered one of the post conditions (presumably mandatory) or is it considered a seperate thing? Personally I don't feel strongly either way, but I would like to be clear on what is meant when the term post conditions is used. i believe post-conditions (whose current definition was said should have been revised in the policy subcommittee concall of Nov. 19) should simply report (if any, and if we want them) the actions not the decision ========================================================== TIM MOSES In one view, there should be a prioritization of the evaluation of policies that hook nodal operations. This is extremely important, since a post-condition could cause the short-circuiting of parsing of the sub-tree under a particular node; one would therefore want higher-priority policies to evaluate before lower priority. Also, if certain policies set attributes that affect the outcome of other policies, one would want those to be of higher priority. if we go towards this we open a can of worms with lots of complications (see treatment of triggers in active database systems). in the concall of Nov. 19 it was said that most probably we do not need such a heavy focus on postconditions, but this again still has to be discussed ================================================== MICHIHARU KUDOH Here are my comments on draft 0.7. Line 131-136 - Are resource classification and the requested action e= nough to identify the applicable policy? I agree that in most cases the res= ource classification and the requested action are used. But there is the ca= se that the applicable policies are classified by subject attribute, for example, the policy for US citizens and the policy for not US citizen= s. In that case, there may be no need for specifying any resource classific= ation. Thus , my suggestion is to add something like "principalClassificatio= n" to the "applicability" element and changes minOccurs attribute to "0" fo= r all element under "applicability". agree I think that is right. You are considering the most complicated policy that allows post-conditions as well as positive and negative permission. [deleted stuff] probably it is better to discuss in the telecon ===================================================================== TIM MOSES Hal - My view is that the PDP won't necessarily evaluate all rules. If it determines that the policy evaluates to true regardless of the condition of some (as yet) unevaluated rules, then it should go ahead and return a "permit" status code. All post conditions associated with rules that were required to evaluate "true" for the policy to evaluate "true" must be executed. agree that if you can take a decision based on something you have you can go ahead and take it. do not think it works though in the case you have not only permissions (e.g., you have negative rules or restrictions) and you have postconditions (which we still have to discuss) ========================================================== HAL It just occurred to me that there is a substantive question related to this. Currently, a policy conflict occurs when you have 2 or more rules and they get different answers. we have not defined what it means to have different answers yet (as we have not defined answers yet). again probably many of the last points will come straigtforward once we have clarified the type of rules we have and how we deal (if we have) with postconditions =================================================================== TIM MOSES Colleagues - I have gleaned the following six issues from the mail list. I suggest we devote approximately twenty minutes to each of these topics during our telecon on Monday. [deleted stuff] taken note will discuss at the telecon tonight ============================================================== HAL I hadn't thought about that one. What you say is logical, but I suspect people will find it unintuitive and perhaps unacceptable. This poscondition stuff is a minefield. I need to think about this more. agreed =============================================================== TIM You propose adding a capability-style model, in addition to the access-control-style model that is currently described. It was my understanding that we decided to avoid the capability-style of model = early on. However, even if my recollection is correct, it is possible that= we made that decision without full consideration of the consequences. S= o, I have included the topic in the list of issues for discussion on Monda= y. i have the same recollection as michiharu, we never committed to ACL style (and explicitely stated few times that a rule may refer to a set of resources), i recall we had discussion about indexing.... talk to you later
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC