Subject: Re: Comments on Access Control Model draft - grant/deny evaluation rules

From: [email-masked] (Richard V Huber)
Date: Wed, 4 Apr 2001 15:55:03 -0400

: From [email-masked] Wed Apr  4 12:09:29 2001
: To: [email-masked] (Richard V Huber)
: From: "Kurt D. Zeilenga" <[email-masked]>
: Subject: Re: Comments on Access Control Model draft - grant/deny
:   evaluation rules
: Cc: [email-masked]
: 
: At 02:14 AM 4/4/01 -0400, Richard V Huber wrote:
: >: >Some of the things that I don't think are clear in the current draft:
: >: >
: >: > - Groups and roles may contain other groups and roles.  Subtrees may
: >: >   contain groups and roles.  Since groups, roles, and subtrees are of
: >: >   different precedence, the interactions need to be spelled out.
: >: 
: >: I would recommend that subtrees, groups and roles not be
: >: recursively evaluated.
: >
: >If groups and roles are not recursively evaluated, I think that the
: >principle of least surprise will be violated - it won't work the way
: >people expect it to.
: 
: Maybe David or someone from the X.500 crowd could comment on
: why X.500 does not recursively evaluate groups and roles their
: ACM.

I'd like to hear it.  There are cases that come up frequently in my
life (e.g. tiered support organizations) where nested groups are really
important and useful as a way to control administrative overhead and
reduce the chances of making security mistakes.  Of course, like most
useful tools, nested groups can be misused.

: X.500(93):
:    nested groups are not supported when evaluating access controls.
: 
: I note that recursive evaluation could be quite expensive.

Yes it could.  But only if you use it in a way that MAKES it
expensive.  It is not expensive for people who do not use nesting or
are careful about nesting.

Rick Huber

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Apr 2001 13:07:36 -0700

>are careful about nesting.

I don't think this is true.  If an implementation does
not support recursion, then it can just check to see
if the authorization DN matches one of the members of
the group.  If the specification requires no recursion,
then implementations just need to check the see if the
authorization identity is one of the listed members.  If
the specification requires recursion, then implementations
would be required to check to see if any listed member
was a group and recurse.  Even if there were no nested
groups, the check itself can be expensive.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Apr 2001 13:15:38 -0700

At 01:07 PM 4/4/01 -0700, Kurt D. Zeilenga wrote:
>authorization identity is one of the listed members.

That was a bit redundant... the first "If ..." sentence
should be ignored.  Sorry for any confusion.

>If the specification requires recursion, then implementations

---

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 04 Apr 2001 13:57:24 -0700

>reduce the chances of making security mistakes.

I strongly agree.  Nested groups are very useful.  If an LDAP server 
supports the Access Control Model, and it supports nesting of groups, then 
it certainly ought to support nesting of groups when evaluating access 
controls.  This is one of the strong points of using LDAP to store access 
control information.

>:    nested groups are not supported when evaluating access controls.

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: robert byrne <[email-masked]>
Date: Thu, 05 Apr 2001 14:55:46 +0200

I also believe the ability to evaluate nested groups is something that
directory users would expect to be able to do and would eventually
request--and so is important for the ACM.

On the implementation side I think caching group membership is a
workable solution that would give acceptable performances.

Rob.