[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] Another proposal (a good one this time)
I agree with your suggestion. It would be good to allow people to use private meta-policy in XACML, if it is specified using Boolean expression. I think the solution would be to add one or more extension points to the schema to specify identity (URI) of their private meta-policies. Best regards, Michiharu IBM Tokyo Research Laboratory, Internet Technology Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428 From: Tim Moses <tim.moses@entrust.com> on 2002/03/04 23:49 Please respond to Tim Moses <tim.moses@entrust.com> To: "'XACML'" <xacml@lists.oasis-open.org> cc: Subject: RE: [xacml] Another proposal (a good one this time) Michiharu - I suggest that, if the formal language for meta-policy is inadequate, we should just drop it, and rely on a plain-language description. XACML can describe a small number of meta-policies, and others can define new ones, either registering them through an XACML process, or keeping them entirely private. All the best. Tim. ----------------------------------------- Tim Moses Tel: 613.270.3183 -----Original Message----- From: Michiharu Kudoh [mailto:KUDO@jp.ibm.com] Sent: Sunday, March 03, 2002 6:35 AM To: 'XACML' Subject: Re: [xacml] Another proposal (a good one this time) Tim, The current syntax for the meta-policy is generic Boolean expression. I agree that Boolean expression is generic and powerful, but in some cases, it is not enough. For example, we need to write the policy rules using precedencies. The policy which has higher precedence overrides the policies that have lower precedencies. If two policies that have the same precedence conflict each other, the global denial meta-policy is used. If two policies having the different precedence, the higher precedence policy always overrides the lower policy. Suppose that we need to write two policies, p1and p2. Each policy has the precedence 1 and 2, respectively. The precedence 1 is the highest precedence: Policy(ID = p1, effect = "permit", precedence = "1", metaPolicyRef = ??) target(sbj1, res1, act1) condition(cond1) Policy(ID = p2, effect = "deny", precedence = "2", metaPolicyRef = ??) target(sbj1, res1, act1) condition(cond2) The decision is determined as follows (assuming that target parameters are satisfied): cond2 T F --------------------------------- cond1 T permit by p1 permit by p1 F deny by p2 indeterminate Which Boolean expression should I specify for this meta-policy? I think that the current meta-policy-1 does not solve this because p2 (deny) does not always override p1 (grant). Do you think it is necessary to allow user-defined meta-policy (based on not Boolean expression) in addition to the Boolean expression type meta-policy? Michiharu Kudo IBM Tokyo Research Laboratory, Internet Technology Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428 From: Tim Moses <tim.moses@entrust.com> on 2002/03/01 05:20 To: "'XACML'" <xacml@lists.oasis-open.org> cc: Subject: [xacml] Another proposal (a good one this time) Colleagues - Here is a new proposal. I believe it addresses many of the issues we are wrestling with in a self-consistent manner. It is one that I (personally) can live with as a point from which to start refining the schema. I would be interested to know whether others can "live with" it, too. All the best. Tim. Proposal There is no syntactic distinction between a rule and a policy. A rule is simply a small policy. So, I'll use the term "policy" exclusively for the remainder of this discussion. A policy statement contains: · a policyId; · a target; · an effect; · a metaPolicyRef and · a condition. Policy meta-data (such as issuer and issue instant) are conveyed in the saml statement wrapper. Target defines the set of names for the: · resources; · subjects and · actions to which the policy statement applies. If the policy statement applies to all entities of a particular type, then the target definition is the root of the applicable name space. An XACML PDP MUST verify that the names of the resources, subjects and actions specified in an authorization decision request are each included in the target of the policy statement that it uses to evaluate the request. MetaPolicyRef specifies the meta-policy by which the policy statement MAY be combined with other policy statements. Condition is a general expression of predicates of attributes. It SHOULD NOT duplicate the exact predicates implied by target. Therefore, it MAY be null. Policy statements may be combined provided that their metaPolicyRefs are identical and that their targets are in identical name spaces. This SHALL be done by including the conditions from the source policy statements in the condition of the combined policy statement, in accordance with the meta-policy. (See draft-xacml-v0.9, Section 6 for an example of a meta-policy). The target of the combined policy statement can be calculated from the targets of the source policy statements. Two approaches are permitted: · the target of the combined policy statement MAY contain the unions of the target definitions for resource, subject and action that are contained in the source policy statements; or · the target of the combined policy statement MAY contain the intersections of the definitions. In the former case, the targets from the source policy statements MUST be included in the form of conditions in the combined policy statement. In the latter case, this step MAY be omitted. In the former case, inapplicable predicates should not be encountered. In the latter case, inapplicable predicates may be encountered. The effect of the combined policy is defined by the meta-policy. The syntax of a combined policy statement is identical to that of a source policy statement. There is an alternative representation for a combined policy, called a policy manifest. It contains: · a policyId; · a target; · a metaPolicyRef and · a list of policy definitions. A policy definition identifies a policy statement by meta-data, (e.g. name). A policy manifest can be converted to a policy statement at any time, by applying the identified meta-policy to the policy statements identified by the policy definitions. The resulting policy statement MUST contain a target computed from the target values in the actual versions of the source policy statements used in the conversion, whereas, the target in the manifest SHOULD be computed from the target values in the actual versions of the source policy statements at the time the manifest was prepared. The significance of the two representations is that, in the first case, the policy statement is generated at the time of preparing the representation, whereas, in the second case, the policy statement can be generated (using the latest versions of the source policy statements) immediately prior to evaluation. PDPs SHOULD support both representations. ----------------------------------------- Tim Moses Tel: 613.270.3183 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC