OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [xacml-comment] Comment on condition element


Hi Anne,

Thanks for your comment - however I think there may still be an issue.
Please see my comments below.

- David

> -----Original Message-----
> From: Anne Anderson [mailto:Anne.Anderson@Sun.com]
> Sent: 16 December 2002 15:56
> To: David Sutton
> Cc: xacml-comment@lists.oasis-open.org
> Subject: Re: [xacml-comment] Comment on condition element
>
>
> David,
> I'm sorry we did not respond to you earlier.  I hope this
> answers your questions.
>
> Anne
>
> On 10 December, David Sutton writes: [xacml-comment] Comment on
> condition element
>  > A rule may hold both a target and a condition, but
>  >
>  > 631 The <Target> element may be absent from a <Rule>.  In this
> case, the
>  > <Rule> inherits its target
>  > 632  from the parent <Policy> element.
>  >
>  > A policy may hold a target but is not permitted to hold a condition.
>  >
>  > Why is a condition not permitted at the policy (or policy set) level?
>
> A "policy" or "policy set" is simply a structure for aggregating
> rules, along with information about how to resolve conflicts
> between the results of the rules.
>
> If you want a condition at the policy or policy set level,
> include a rule.

By including a rule with a condition is not the condition scope limited to
that rule only - not the policy or policy set? So no other rules in the set
would be affected by a condition in any other rule in the policy or policy
set.

>
>  > If a policy target is intended to server the function of a
> rule target in
>  > the absence of a target in the rule then why can a policy
> level condition
>  > not also be allowed?
>
> There may be many rules that apply to the same target, so we
> allowed a rule to inherit the policy target rather than having to
> repeat the target in each rule.

Makes sense - my query is that this makes so much sense should it not be
extended to conditions too?

>
>  > An example where this would be useful is if policy objects are
> identified
>  > with roles. In this context there is an over-arching
> policy-wide reqirement
>  > that the subject be a member of the associated role. This
> would probably
>  > need to be described as a condition - and most conveniently as a policy
>  > level condition. However this is not possible in the current
> specification.
>
> You could make the role requirement part of the target of of the
> policy.

Based on some recent comment I understand that the requirement that target
elements be indexable may have been relaxed. If this is so then it would be
possible to make the role requirement part of the policy target (assuming
for example that role membership would be a subject attribute).

However, if a specific implementation chose to retain the target indexing
requirement then the only way to enforce the subject role membership
requirement would be by a condition. Since there may be many rules in a
given policy and since the rule can't inherit the policies condition (since
policies don't have one) then the condition has to be repeated in the target
in each rule.

So, I think the original query still stands:

Why not allow a policy or policy set to hold a condition and allow this to
be inherited by rules?

On a related secondary note I'm not clear on what is the behaviour for a
rule that does have a target when its enclosing policy or policy set also
has a target? Is the rule bounded by both the rule target and the inherited
target or does a rule only inherit a target when the rule has no target
element itself?

>
> Anne Anderson
> --
> 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
>
>
> ----------------------------------------------------------------
> 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