[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Re: policy model, part 1
Simon's model corresponds to Carlisle's "Sub-Model 1: The Real Database", which I call a "Set of Rules Model". My objection to this model is the writer of each rule must be all-knowing: all rules are on an equal footing, so the writer of each rule must know exactly under which conditions that rule will apply. It also does not allow for delegation of policy for specific situations. Some enterprises may want to follow this model, but unfortunately it is not compatible with the hierarchical, delegated policy model that other enterprises may want to follow: A referenced policy is N/A if its applicability conditions are FALSE: Base Policy: <policy> <AND-omitting-N/A> NecessaryReferencedPolicy1, NecessaryReferencedPolicy2, ... <OR> SufficientReferencedPolicy1, SufficientReferencedPolicy2, ... </OR> </AND-omitting-N/A> </policy> A hierarchical, delegated policy model, on the other hand, can support the "Set of Rules" model: A rule is N/A if any of the predicates on Subject, Action, and Resource is FALSE: Base Policy: <policy> <and-omitting-N/A> NecessaryRule1, NecessaryRule2, ... <or> SufficientRule1, SufficientRule2, ... </or> </and-omitting-N/A> </policy> The difference is that referenced policies may in turn reference other policies, while rules are complete in themselves. On 14 February, Simon Godik writes: policy model, part 1 > Note: Rules are extensible: ie we should be able to accomodate > provisional authorization semantics (Michiharu), deny semantics, etc. Accommodating extensible semantics at the rule or referenced policy level, where those semantics affect the base policy evaluation, is incompatible with efficient hierarchical, distributed policy evaluation. > Rule components. > The simpliest form of a subject is authenticated identity of a requestor. > Another simple form for a subject is a list of groups and roles. > In general subject is a boolean expression over subject attributes. > eg: user.id='foo' and user.group='xacml_tc' > > The simpliest form of a resource is a resource name. Another simple form > of resource is resource group name. In general, resource is a boolean > expression over resource attributes. > eg: res.owner='gates' Having the "selector" predicates be boolean expressions over attributes is not consistent with the requirement I have heard that "selector" predicates be simple regular expressions that allow fast selection of potentially applicable rules or referenced policies. The attributes may not be in the initial query, and may require lookup by an Attribute Authority. Simon's proposed syntax is still compatible with the proposal to have expanded applicability predicates, which is compatible with hierarchical, distributed policies. <applicablePolicy \> <resource>"simple resource match"</resource> <subject>"simple subject match"</subject> <action>"simple action match"</action> <fullApplicability> [arbitrary boolean expression on arbitrary elements of the request or attributes derivable from the request or environment] </fullApplicability> <policy> [arbitrary boolean expression on arbitrary elements of the request or attributes derivable from the request or environment] </policy> </applicablePolicy> > If both authorizations and restrictions are present in the policy (4) rules > are combined with a formula > (rs1 /\ rs2 /\ ... /\ rsM) /\ (r1 v r2 v ... rK) > That means all applicable restrictions must be satisfied and at least > one applicable authorization must be satisfied. See my Boolean Policy example at the top. It is exactly equivalent. > 2 - policy is treated as a black box and it is logically combined with > a rule in another policy. In this case policy is queried and result of the > query is used directly in rule evaluation. I don't understand this. How is a rule extracted from another policy? What "rule" is being evaluated? > 3 - policy is unpackaged and rules are merged directly into another policy. > This is policy merging. This is the most difficult option even if algorithms > in both policies are the same. If algorithms are different one policy should > be reformulated. I don't see the difficulty if you stick with the "rules" model where rules are either necessary or sufficient. For each policy, add all "necessary" rules to the <and> clause of the base policy, and add all "sufficient" rules to the <or> clause of the base policy. Then evaluate. Maybe you are referring only to policies having an evaluation URI that has semantics other than "necessary" or "sufficient"? Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC