[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] xacml model subcommittee - minutes of Jan.7 concall
MINUTES OF THE 7 JAN. 2002 CONCALL ================================== Anne noted that a suggestion previously made by Tim on post-conditions was not reflected in the issues list. The suggestion was that only the post-conditions associated with the rules that were evaluated to get to an access decisions should be executed (this in response to the comment that post-conditions have the drawback of requesting the evaluation of *all* rules). Pierangela notes that a possible drawback of this approach is that deterministic behavior may be lost. For instance, there may be N rules applying to an access request. If the evaluation of 1 of them brings to a ``permit'' decision (so there is no need to evaluate the others); then, you would ignore the postconditions possibly associated with the other N-1. Different executions of the same request on the same state could then have a different behavior (because a different rule is considered as authorizing the request). Pierangela to update the issue list to include Tim's suggestion and related comment. There was a discussion about triplet vs. pre-condition option. Simon mentions that attributes with the same name for principals and resources could be a problem. As an example, you have an attribute named ``color'' for resources and principals, how do you know which one you are referring to? Anne and Carlisle note that the attribute will be referred to with the complete path expression so you woud know if you are referring to the principal or the resource. Simon agrees on it but fears that mixing predicates on all attributes in a single expression could bring confusion for simple cases when - in the triplet solution - the element in which the predicate appears could solve the ambiguity. Ernesto draws the attention on policy composition (which is a recent issue) to see if everybody agrees on how the problems associated with it are listed. In particular he asks Tim whether an applicable policy can refer to several policies (the schema assumes one single policy). there are three possible approaches: 1) there may be more policies applicable to each resource which will be stated in different policy documents with overlapping targets [Hal] 2) we have a PRP, that takes the fragments and unifies them in a single policy (applicable policy) [Tim]. PRP returns a self-contained applicable policy to the PDP. In principle the applicable policy can be distributed in different documents (overlapping targets), ensuring that retrieval brings you the complete set of rules is done at run-time. 3) logical expressions of policies [example in issue list] or policy fragments [Anne]. There is a single applicable policy for each request but the applicable policy can refer to (be a logical expression of) different policies (which could be distributed). Each Policy can be a path expression that points to a set of rules. Tim says that the current schema supports the first two approaches, not the last (as it does not allow logical expressions of policies). Ernesto recalls Michiharu's proposal of pointing to an external URI where the way policies should be combined is stated. Anne says that at the last concall Michiharu stated that his proposal was a ``radical'' extension, not compatible with the current solution (use of ``deny'' in solving policies would require you to change the language and the semantics). In particular, Anne mentions a problem with negative authorizations that could have a ``global effect''. For instance, if you have a policy composition P1 OR P2, even if P1 says that access should be granted you cannot stop access control, you should evaluate P2 as well, as it may contain negative rules which, in a denial-takes-precedence policy should win over P1 decision. Pierangela agrees on this but notes that in a previous concall it was agreed that the scope of the negative rule should be confined within a policy. Pierangela notes that it might still be possible to allow a policy to explicitely state a negation allowing policies to return a 3-valued decision. Composition operators should be redefined accordingly. This matter is to be investigated further. Allowing a 3-valued decision and refining the operators accordingly may increase expressiveness with limited complications. For instance you can express a policy that says ``grant access if the department permits (P1 retuns `permit') and central administration does not have any objection to it (P2 does not return `deny'). Note that in a case of a 3-valued solution, returning `deny' is different from returning `null' (instead in a 2-valued scenario null is mapped to the default decision).. Anne recalls that in previous concalls it was mentioned that 80\% of the requirements should be met by the core syntax. If negative policies are part of the requirements, negative policies should be part of the core. Anne starts a discussion regarding whose task it is to state how policies should be combined. Is it for the PDP, PEP, PRP? Follows some discussion (i got lost in it), Tim to supply a diagram via email to clarify the matter. Ernesto draws attention to the problem of composition w.r.t. distribution of policies. Assuming composition is because of distribution of policies, we should decide whether we want to support composition explicitly. Pierangela mentions that distribution may mean conceptual distribution (not necessarily geographical). I may want to be able to express logic expressions combining policies which are maintained by separate authorities, regardless of their physical location. Tim says that the current schema should be able to accomodate this last case (details w.r.t. how to be provided). ACTIONS: - Pierangela to update the issue list according to tonight discussion - Ken to organize the issue list and number issues (wait for tomorrow version) - Tim to update the document on changes people already agreed on - Tim to update the glossary to reflect changes agreed - Everybody who has input for the glossary to send a msg to Tim.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC