[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] RE: policy model, part 1
Michiharu, I agree with renaming <policy> to something else like <constraints> and renaming <policyStatement> to <rule>. Elements for any subject and any resource are also needed. I also agree that <policyStatement> is a collection of <rule>s. I think predicates are put under <resources>, <subjects>, <actions> to designate certain attribute expressions as targets. For example, if I want to use subject attribute 'administrator' as a target, I put predicate expression administrator=true under <subjects>. Simon ----- Original Message ----- From: "Michiharu Kudoh" <KUDO@jp.ibm.com> To: <xacml@lists.oasis-open.org> Sent: Monday, February 25, 2002 4:49 AM Subject: Re: [xacml] RE: policy model, part 1 Basically, I agree to Carlisle's suggestion and Simon's proposal. I have a comment on the structure of the policyStatement in v0.9 (not Carlisle's proposal) that is structured: <policyStatement> <target> <subjects> <resources> <actions> </target> <policy> <predicate> </policyStatement> From my viewpoint, the above structure should appear: <ruleStatement> <target> <subjects> <resources> <actions> </target> <conditions> </ruleStatement> This goes with Carlisle's proposal. Since <policyStatement> in v0.9 corresponds to the rule statement, <policyStatement> should be <ruleStatement> or <rule>. Since <policy> in the <ruleStatement> would be misleading, it should be <conditionStatement> or <condition>. (my concern is that <Condition> is also used in SAML in different meaning but I ignore that here). I guess why <policy> is used here because the higher policy structure (PolicyStatement in Carlisle's suggestion below) reuses the schema. My suggestion is to distinguish two structures and use <conditions> (or more intuitive name ) <ruleStatement>? Moreover, I don't quite understand why <predicate> is placed under <subjects>, <resources>, <actions>, and <policy>. It does not seem to convey a useful information. If it was an extension point, it could... For the meaning of "any", I could live with either way: missing of <subject> etc. or explicit element like <AnySubject>. Another option would be to create <true> or <any> element in PredicateExpressionType. Then <subjects><true/></subjects> could mean <AnySubject>. As to Effect, I can understand the intention of this attribute and understand that its primary purpose is a reference parameter in meta-policy. I like to have this in explicit way like this. My concern is that the usage of this Effect in meta-policy. I don't quit understand the Carlisle's intention of "basic", "compoud", "independent", and "dependent" of <Policy> in <PolicyStatement>. My impression is that it would be better to focus more on specific use case as well as to provide generic syntax and semantics. One of the typical way of using a set of rules is to provide the notion of "rule set", that means <Policy> refers a set of <ruleStatement> and they are combined with <or> combinator. <policyStatement> <policy> <or> <policyRef policyID="Policy1" .../> <policyRef policyID="Policy1" .../> <policyRef policyID="Policy1" .../> </or> </policy> </policyStatement> I think that the above notion should be represented using more specific element like <ruleSet>. The rule set returns true (or permit?) if one of the rule becomes true: <ruleSet> <ruleRef ruleID="Rule1" .../> <ruleRef ruleID="Rule2" .../> <ruleRef ruleID="Rule3" .../> </ruleSet> I mean that the rule here represents the usual notion of rule used in rule-based systems and rules in prolog language. As far as I know, rules are combined by OR semantics and they are called rule set. I am not saying that this is only the case we should provide but this is one of the typical usage of rules. Michiharu IBM Tokyo Research Laboratory, Internet Technology Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428 From: Carlisle Adams <carlisle.adams@entrust.com> on 2002/02/20 06:51 To: "'xacml@lists.oasis-open.org'" <xacml@lists.oasis-open.org> cc: "'simon@godik.com'" <simon@godik.com> Subject: [xacml] RE: policy model, part 1 Hi all, Many thanks to Simon for writing up his view of the policy model -- his thoughts are now much clearer to me! I'm feeling optimistic because I don't think that the various views floating around the TC are that far apart. I'm trying to put together a model that reconciles Simon's thoughts (which are based, at least in part, on work by Michiharu, Pierangela, and Ernesto) and what's in the v0.9 draft, but before going to XML syntax I'd like some confirmation that we can reach consensus on the main features. So, some feedback on the following proposal would be welcome. Carlisle. A RuleStatement contains the following items. - a RuleCore, which is a triple ("subject", "action", "resource"), although one or two of the components may be missing (meaning "any"). The syntax would essentially be "RuleType" (that is, each component is a PredicateExpressionType), but in practice we would expect that the expressions used would be fairly simple ones. - a Condition, which is a combination of predicates that must evaluate to true for this rule to fire. The syntax would essentially be PredicateExpressionType and may be arbitrarily complicated. - an Effect, which says how this rule is expected to contribute to a policy result. The syntax would essentially be EffectType, but extended to include another enumeration. The possibilities are - "Permit" (Simon's "authorization" rule which, if TRUE, will contribute to a "Permit" decision but if FALSE may not cause a "Deny"), - "RequiredPermit" (Simon's "restriction" rule which must be TRUE before a "Permit" decision can be returned and if FALSE will force a "Deny"), and - "Deny", which, if TRUE, will cause a "Deny" decision to be returned. A PolicyStatement contains the following items. - an Identifier, so that it may be referenced. - a Name (optional). - a Comment (optional). - perhaps some other items (e.g., Issuer, or IssueInstant), even if these might also be part of the SAML assertion envelope (see MetaPolicyStatement below...). - a Target, which specifies the applicability of the policy. The syntax would essentially be RuleType. Each component (i.e., "subject", "action", "resource") is, in the worst case, the union (i.e., the "or") of the corresponding components in the included RuleCore or Target expressions, but in many cases a simpler equivalent expression may be found. - a Policy. There are four possibilities for this: - a "basic", "independent" policy - a "basic", "dependent" policy - a "compound", "independent" policy - a "compound", "dependent" policy Definitions: - a "basic" policy is a combination of rules; - a "compound" policy is a combination of policies (this is what we've called a "base policy" or a "higher-level policy" in the past, but "compound" may be more intuitive...); - an "independent" policy explicitly includes the combining algorithm and therefore can be evaluated entirely on its own; - a "dependent" policy points to (i.e., references) an external, generic combining algorithm (a metapolicy) and therefore can be evaluated only in conjunction with that metapolicy. A MetaPolicyStatement contains the following items. - an Identifier, so that it may be referenced. - a Name (optional). - a Comment (optional). - an Algorithm for combining predicates, which may be predicates about rules (such as "Permit" and "Deny") or predicates about policies (such as "Issuer" or "IssueInstant"). The syntax would essentially be PredicateExpressionType. ---------------------------------------------------------------- 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