Subject: Re: grant / deny precedence indraft-ietf-ldapext-acl-model-04.txt

From: Ellen Stokes <[email-masked]>
Date: Wed, 20 Oct 1999 00:36:20 -0500

Brian,
I agree with your precedence examples and have no problem using them in the
draft.
Precedence order, however, could be a sticky problem.  I could see a
precedence
of (lowest--least specific) group, role, access-id (highest--most specific).
But if we allow other types of subjects, such as IP address (and heaven
knows what
else people would want to use), it's not clear where to include those in
the precedence.
So, the question to the mailing list is:  Do we want to include subjects
other than
the classic ones of acccess-id, role, and group?  And if so, I'm not sure
we could state
a default precedence when more 1 additional subject is added to the classic
set of subjects.
Thoughts?
Ellen

At 04:02 PM 10/19/1999 -0600, Brian Jarvis wrote:
>In general, I agree.  But I think the more specific the ACI, the more
precedence it should have.
>
>Example #1:
>BJarvis is a member of Group1
>aci: 1.2.3.4#subtree#deny;r,w;[all];#group#cn=Group1
>aci: 1.2.3.4#subtree#grant;r,2;[all];#access-id#cn=BJarvis
>
>I maintain that access-id is more specific than group and thus in example
#1, grant has precedence over deny.
>
>This implies that we need to define a precedence order for dn-types.
>I would propose (lowest--least specific) group, role, ip-address?,
access-id (highest--most specific).
>
>
>Example #2:
>aci: 1.2.3.4#subtree#deny;r;w;[all];#group#cn=Group1
>aci: 1.2.3.4#entry#grant;r;w;[all];#group#cn=Group1
>
>I maintain that entry is more specific than subtree and thus is in example
#2, grant has precedence over deny.
>
>This implies that we need to define a precedence order for scopes.
>I would propose (lowest--least specific) subtree, <level>, entry
(highest--most specific).
>
>When ACIs are of equal precedence, I think deny should override grant as a
safety issue.  When they are not of equal precedence, I maintain that the
precedence order should determine ACI overrides rather than grant/deny.
>
>--the walrus
>a.k.a. Brian Jarvis
>[email-masked]
>
>>>> prasanta Behera <[email-masked]> 10/19/1999 11:32:30 >>>
>
>
>David Ward wrote:
>
>> I agree.  I would suggest making it very clear that deny takes
precedence over grant when :
>>
>> 1) there are two conflicting aci values
>> 2) there is no aci information ( deny is the default )
>
>I agree. It makes sense.
>/prasanta
>
>>
>>
>> David
>>
>> >>> Ellen Stokes <[email-masked]> 10/19/99 3:57:27 AM >>>
>> Yes, we want to be very specific about behavior for interoperability.
>> So, given your example, there are 2 rules that need to be added to
>> the draft:
>> 1.  More specific policies must override less specific ones (e.g.
>> individual user
>> entry in ACL SHOULD take precedence over group entry) for the evaluation of
>> an ACL.
>> 2.  Deny takes precedence over grant.
>> Ellen
>>
>> At 05:05 PM 10/12/1999 -0600, David Ward wrote:
>> >Is there a precedence for the grant / deny actions?  If there are two
>> identical ACI values except for the action, which one takes precedence?  An
>> example would be:
>> >
>> >             aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ,
c=US
>> >             aci: 1.2.3.4#subtree#deny;r;attribute1#group#cn=Dept XYZ,
c=US
>> >
>> >Is this server implementation dependent?  I don't think it should be.
>> However, if it must be for some reason I haven't considered, a server
>> should at least advertise its precedence.  This information could be put in
>> the Root DSE object.  Without this information, different ldap
>> implemenations may not be able to interoperate and maintain desired access
>> control behaviors.
>> >
>> >
>> >David
>> >
>> >
>
>
>

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 21 Oct 1999 23:17:31 +0100

> Brian,
> I agree with your precedence examples and have no problem using them in
> the draft. Precedence order, however, could be a sticky problem.  I could
> see a precedence of (lowest--least specific) group, role, access-id

I also support this precedence ordering (except that I thought your 
group and role were equivalent in terms of specificity)

>But if we allow other types of subjects, such as
> IP address (and heaven knows what else people would want to use), it's not
> clear where to include those in the precedence. So, the question to the
> mailing list is:  Do we want to include subjects other than the classic
> ones of acccess-id, role, and group?

You will have to say precisely what you mean by classic ones 
before people can give common answers, I believe

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: Ellen Stokes <[email-masked]>
Date: Thu, 21 Oct 1999 21:47:27 -0500

David (and others),
Here's the question:  Do we want to include subjects other
than access-id, role, and group?
Ellen

---

From: "David Chadwick" <[email-masked]>
Date: Fri, 22 Oct 1999 18:28:55 +0100

> than access-id, role, and group?

Like Jim, I do not recognise a difference from the access control 
perspective between the currently defined role and group. Therefore 
I would suggest delete role.
I do also suggest that subtree is added, as this is clearly different to 
group (and role).

David

David Chadwick