Subject: please publish (draft-ietf-ldapext-acl-model-05.txt)

From: Ellen Stokes <[email-masked]>
Date: Fri, 10 Mar 2000 13:41:05 -0600

Please publish.

ldapext folks:  Attached is the access control model draft I sent to the 
drafts editor.  Also
attached is a summary of the changes in this draft - I think I've reflected 
all email since
October in this draft.  Comments welcome.  I'd like to see this version go 
to last call...

Thanks.
Ellen

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 14 Mar 2000 00:35:34 -0000

Ellen
Please find attached my comments on model-05
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

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

Comments on ACL model 05

i) I think it is extra clutter to have familyOID as the first component of the 
ldapACI attribute type, and does not buy us anything. If you want to define 
another set of permissions, then simply give them a new attribute type (e.g. 
ldapACIv2) which is itself an OID. It serves no good purpose to have one OID 
for the ldapACI attribute then another OID for the family. You might as well 
have just one OID that means precisely one set of permissions and access 
control information.

ii) I made a comment on 04 about ReadDN that I don't believe has been 
addressed yet. There is a difference between letting someone have access to an 
entry they know exists, and ones they don't know exist. I.e. there is a 
difference in permissions needed for the base object of a Search and the entries 
beneath the base object (the latter is a greater permission than the former). At 
the moment BrowseDN gives the latter permission, but there is not the lesser 
permission of accessing an entry whose name you already know. This would 
call for a ReadDN permission I believe. Comments please on this.

iii) Precedence of privilege dnTypes. I would argue that role comes higher than 
group as it is more specific. By this I mean that group membership is usually 
conferred on more people than are roles (and as you said in October, roles can 
be regarded as groups with permissions). I would expect my role of abc 
administrator to have more weight than simply a member of the IETF LDAP 
group.

iv) On the same vein, can you explain why IP address should be higher than 
access-id, when the former can be used by multiple people, the latter by only 
one. It is the issue of specificity again. The more specific a dnType the higher 
its precedence should be.

v) In my comments to version 4, I mentioned that delete permission for attribute 
values could be needed, as with Modify Entry you both add values and delete 
values and replace values (I took your write values permission to mean add). 
With separate permissions you can allow some people to add, some to delete, 
and some to do both. You said you would look into it, but I don't remember 
your reply to this. I would suggest changing "write" to "add", and adding 
"delete".

vi) Why can an acl entry only confer multiple rights on a single attribute name. I 
would have expected <attr> to allow multiple attribute names within it. 
(Version 4 allowed this.) Your later example shows the ldapACI being 
repeated in order to give SysAdmins access to attr2 and attr3. Why was the 
restriction introduced?

vii) Section 9 introductory paragraph talks about manipulating access rights and 
getting and setting them. But as I read it, the section only provides a 
mechanism to read them, not to update, set or manipulate them. Can you alter 
the wording please.

---

From: Ellen Stokes <[email-masked]>
Date: Wed, 15 Mar 2000 10:15:28 -0600

Responses embedded below and prefaced by (EJS)
Ellen

>Please find attached my comments on model-05

(EJS) We could do as you suggest, but I'd rather not.  I believe that it is 
better
to have a single attribute known for ldap access control rather than 
proliferate
more attributes for this purpose and let the family OID control  the remaining
information.  This provides an application with one way of accessing access
control information, although it may still have to parse out the information.
If we start propagating different attributes for ldap access control, then 
it is
difficult, if not impossible, for the application to know which ldap access 
control
attribute it needs to invoke.

>call for a ReadDN permission I believe. Comments please on this.

(EJS) BrowseDN is ReadDN.  BrowseDN allows that DN in a search.  This allows
someone access to only information that he has been authorized for.  A person
may know that an entry exists, but just because he does have that knowledge
does not mean he can access it.  Likewise, if a person doesn't know an entry
exists doesn't mean that he should be able to discover it.

>administrator to have more weight than simply a member of the IETF LDAP

The following is a cut and paste from Bob Blakley's reasoning in his prior 
email
on the precedence stated in this current draft.

The underlying implementation of the access decision function (which looks
at ACL entries and compares them against the subject's credentials to render
a yes/no decision about a particular access request) may treat "group" entries
differently from "role" entries. For example, it might implement "union 
semantics"
for groups but "intersection semantics" for roles. Thus if an ACL contained 
4 entries:

group1 : grant (read, search)
group2 : grant (update)
role1 : grant (read, search)
role2 : grant (update)

A subject belonging to group1 and group2 would be granted access (because
union semantics grants access if any group grants access), but a subject
belonging to role1 and role2 would be denied access (because intersection
semantics grants access only if all roles grant access).

This ability to distinguish groups and roles semantically is important. It
permits security administrators to have two different subject collection
constructs with different granularities and different dynamism.  Roles
(not role attributes -- actual roles) are typically defined at a fairly high
organizational level and changed infrequently. The authorizations granted
to role attributes mirror the organizational responsibilities associated with
the roles.

However in modern organizations roles don't describe the "entire job" of an
individual -- the VP of marketing may be assigned (for a short time) to a task
force evaluating the technical competitiveness of a product. To participate in
this activity, she may need access to engineering data to which her job role
(or roles) as marketing VP don't entitle her. The CFO and the East Region
Helpdesk Director may also be on the taskforce, and may need access to
the same data. To grant the desired access to all three of these individuals,
it would be possible to individually authorize them to the data -- but this 
would
be bad for several reasons. The first is scale -- for three people this would
be feasible, but for 30 it would be unpleasant, and for 3000 it would be 
impractical
(especially in organizations which run lots of task forces or have lots of 
matrix
management). The second is that if you simply put individual entries on the
ACL, you might forget who the individuals are and why they're on the ACL.
In this case you'd very likely forget to take them off the ACL when the task
force ended, thus creating a need-to-know violation.

On the other hand, defining a new "role" for the task force is bad also: task
force membership isn't really a role; it's really an assignment. Adding lots
of roles to the role namespace pollutes the policy environment and makes
it very difficult for the enterprise policy administrators, whose job is 
defining
work roles and their proper authorizations, to do their work.

What's really called for is defining a "group" -- an ad-hoc collection of 
users
who can be authorized to the specific set of resources for the duration of the
project as an *exception* to the role-based policy. The group should be given
an evocative name (like the name of the project) and should be authorized to
the resource. When the project ends, the group can be deleted, and its entries
can be removed from the associated resource ACLs.

As this example suggests, in order to support using groups as exceptions to
roles, group attributes and role attributes need to have different precedence.
As the example also suggests, I think groups should have *higher* precedence
than roles, since roles are essentially a coarse-grained, static, subject
collection, and groups are a fine-grained, dynamic subject collection.

Note that many existing security models, including ISO, ECMA-138, CORBA,
and others include both groups and roles (and type-distinguish the two).

For ipAddress, we ought to consider how it will be used. Normally the
requirements are for restricting access to a resource so that either (1) it 
can
be accessed ONLY from a particular workstation or group of workstations,
or (2) it can NEVER be accessed from a particular workstation or group of
workstations.

Hence, the precedence in this current draft (05), (highest to lowest):
ipAddress
access-id, kerberosID
group
role
subtree

Comments?

>its precedence should be.

(EJS) See response to iii) above.

>your reply to this. I would suggest changing "write" to "add", and adding

(EJS) The write (w) permission is for the ldap_modify operation where that
single operation allows add, delete, and replace.  We can certainly change
this so that write permission is broken into two permissions (add and delete)
where replace requires both add and delete.  Proposed permissions for
this change are 'w' for write/add and 'o' for write/delete (obliterate) 
where write/replace
operation requires both w and o to be set.  The question in doing this is do
people/applications really make this fine of a distinction in write 
permissions, for
example where someone may write/add but not write/delete (and vice-versa)?
Comments?  What's the consensus here?

>repeated in order to give SysAdmins access to attr2 and attr3. Why was the

(EJS)  Several people complained that the syntax was too complicated and
hence the restriction.  We can certainly remove the restriction so attribute:
can have one or more attributes.  So you can then specify a grouping of
attributes by collection: <collectionname> or by attribute: <attr>*.
Comments?  What's the consensus here?

>mechanism to read them, not to update, set or manipulate them. Can you alter

(EJS)  You are correct.  I will alter the wording to reflect read, not 
write (oversight
on my part).

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 16 Mar 2000 00:51:12 -0000

Date forwarded: 	Wed, 15 Mar 2000 08:16:23 -0800 (PST)
Date sent:      	Wed, 15 Mar 2000 10:15:28 -0600
To:             	[email-masked], [email-masked]
From:           	Ellen Stokes <[email-masked]>
Subject:        	Re: please publish (draft-ietf-ldapext-acl-model-05.txt)
Copies to:      	[email-masked], [email-masked]
Forwarded by:   	[email-masked]

> >i) I think it is extra clutter to have familyOID as the first
> >component of the ldapACI attribute type, and does not buy us
> >anything. If you want to define another set of permissions, then
> >simply give them a new attribute type (e.g. ldapACIv2) which is
> >itself an OID. It serves no good purpose to have one OID for the
> >ldapACI attribute then another OID for the family. You might as well
> >have just one OID that means precisely one set of permissions and
> >access control information.
> 
> (EJS) We could do as you suggest, but I'd rather not.  I believe that
> it is better to have a single attribute known for ldap access control
> rather than proliferate more attributes for this purpose and let the
> family OID control  the remaining information.  This provides an
> application with one way of accessing access control information,
> although it may still have to parse out the information. If we start
> propagating different attributes for ldap access control, then it is
> difficult, if not impossible, for the application to know which ldap
> access control attribute it needs to invoke.

Sorry, I dont buy this, since the application will have to know all the 
family OIDs if it is to be able to understand the meaning and content 
of the aci. There is thus no difference between having to know the 
OIDs of families or the OIDs of the attribute types. You have not 
saved anything by nesting families in a single attribute type (other 
than forcing them to all have the same syntax). Different code will be 
needed for each family OID, just as different code will be needed if 
it were different attribute types. Therefore I still believe the family 
OID is just extra clutter that actually buys you nothing.
  
> >addressed yet. There is a difference between letting someone have
> >access to an entry they know exists, and ones they don't know exist.
> >I.e. there is a difference in permissions needed for the base object
> >of a Search and the entries beneath the base object (the latter is a
> >greater permission than the former). At the moment BrowseDN gives the
> >latter permission, but there is not the lesser permission of
> >accessing an entry whose name you already know. This would call for a
> >ReadDN permission I believe. Comments please on this.
> 
> (EJS) BrowseDN is ReadDN.  

I know that. What I was saying is that there is not a lesser 
permission than BrowseDN that only allows a read if you know the 
name beforehand. (Consider web access for example. There are 
many web pages that you can only access if you know the URL 
beforehand, but cannot browse to look for them)

>BrowseDN allows that DN in a search.  This
> allows someone access to only information that he has been authorized
> for.  A person may know that an entry exists, but just because he does
> have that knowledge does not mean he can access it.  Likewise, if a
> person doesn't know an entry exists doesn't mean that he should be
> able to discover it.

Agreed, but you do not currently have a way of allowing someone to 
access something they know exists and not have access to 
something they dont know exists. This is what I am suggesting 
should be added.

> 
> 
> >iii) Precedence of privilege dnTypes. I would argue that role comes
> >higher than group as it is more specific. By this I mean that group
> >membership is usually conferred on more people than are roles (and as
> >you said in October, roles can be regarded as groups with
> >permissions). I would expect my role of abc administrator to have
> >more weight than simply a member of the IETF LDAP group.
> 
> The following is a cut and paste from Bob Blakley's reasoning in his
> prior email on the precedence stated in this current draft.
> 
> The underlying implementation of the access decision function (which
> looks at ACL entries and compares them against the subject's
> credentials to render a yes/no decision about a particular access
> request) may treat "group" entries differently from "role" entries.
> For example, it might implement "union semantics" for groups but
> "intersection semantics" for roles. Thus if an ACL contained 4
> entries:
> 
> A subject belonging to group1 and group2 would be granted access
> (because union semantics grants access if any group grants access),
> but a subject belonging to role1 and role2 would be denied access
> (because intersection semantics grants access only if all roles grant
> access).
> 
> This ability to distinguish groups and roles semantically is
> important. It permits security administrators to have two different
> subject collection constructs with different granularities and
> different dynamism.  Roles (not role attributes -- actual roles) are
> typically defined at a fairly high organizational level and changed
> infrequently. The authorizations granted to role attributes mirror the
> organizational responsibilities associated with the roles.
> 
> However in modern organizations roles don't describe the "entire job"
> of an individual -- the VP of marketing may be assigned (for a short
> time) to a task force evaluating the technical competitiveness of a
> product. To participate in this activity, she may need access to
> engineering data to which her job role (or roles) as marketing VP
> don't entitle her. The CFO and the East Region Helpdesk Director may
> also be on the taskforce, and may need access to the same data. To
> grant the desired access to all three of these individuals, it would
> be possible to individually authorize them to the data -- but this
> would be bad for several reasons. The first is scale -- for three
> people this would be feasible, but for 30 it would be unpleasant, and
> for 3000 it would be impractical (especially in organizations which
> run lots of task forces or have lots of matrix management). The second
> is that if you simply put individual entries on the ACL, you might
> forget who the individuals are and why they're on the ACL. In this
> case you'd very likely forget to take them off the ACL when the task
> On the other hand, defining a new "role" for the task force is bad
> also: task force membership isn't really a role; it's really an
> assignment. Adding lots of roles to the role namespace pollutes the
> policy environment and makes it very difficult for the enterprise
> policy administrators, whose job is defining work roles and their
> proper authorizations, to do their work.
> 
> What's really called for is defining a "group" -- an ad-hoc collection
> of users who can be authorized to the specific set of resources for
> the duration of the project as an *exception* to the role-based
> policy. The group should be given an evocative name (like the name of
> the project) and should be authorized to the resource. When the
> project ends, the group can be deleted, and its entries can be removed
> from the associated resource ACLs.
> 
> As this example suggests, in order to support using groups as
> exceptions to roles, group attributes and role attributes need to have
> different precedence. As the example also suggests, I think groups
> should have *higher* precedence than roles, since roles are
> essentially a coarse-grained, static, subject collection,  and groups
> are a fine-grained, dynamic subject collection.
> 
> Note that many existing security models, including ISO, ECMA-138,
> CORBA, and others include both groups and roles (and type-distinguish
> the two).

I follow this and agree with the example as far as it goes, but fail to 
see how the example supports the case for multiple role permissions 
to be intersection and not union, which appeared to be the rationale 
for the example, did it not? Also Bob has not said how role and 
group should combine together - would it be union or intersection? If 
it were union, then the precedence of group could be below role and 
his example would still work, would it not? Therefore can Bob explain 
why the example is arguing for group above role.

> requirements are for restricting access to a resource so that either
> (1) it can be accessed ONLY from a particular workstation or group of
> workstations, or (2) it can NEVER be accessed from a particular
> workstation or group of workstations.

I can buy into this one as the highest precedence for the reason 
stated.

> ipAddress access-id, kerberosID group role subtree
> 
> 
> 
> >v) In my comments to version 4, I mentioned that delete permission
> >for attribute values could be needed, as with Modify Entry you both
> >add values and delete values and replace values (I took your write
> >values permission to mean add). With separate permissions you can
> >allow some people to add, some to delete, and some to do both. You
> >said you would look into it, but I don't remember your reply to this.
> >I would suggest changing "write" to "add", and adding "delete".
> 
> (EJS) The write (w) permission is for the ldap_modify operation where
> that single operation allows add, delete, and replace.  We can
> certainly change this so that write permission is broken into two
> permissions (add and delete) where replace requires both add and
> delete.  Proposed permissions for this change are 'w' for write/add
> and 'o' for write/delete (obliterate) where write/replace operation
> requires both w and o to be set.  The question in doing this is do
> permissions, for example where someone may write/add but not
> write/delete (and vice-versa)? Comments?  What's the consensus here?

Ellen I think this is the best way forward, to see what people actually 
want. I was raising the topic for precisely that reason.

> 
> 
> >vi) Why can an acl entry only confer multiple rights on a single
> >attribute name. I would have expected <attr> to allow multiple
> >attribute names within it. (Version 4 allowed this.) Your later
> >example shows the ldapACI being repeated in order to give SysAdmins
> >access to attr2 and attr3. Why was the restriction introduced?
> 
> (EJS)  Several people complained that the syntax was too complicated
> and hence the restriction.  We can certainly remove the restriction so
> attribute: can have one or more attributes.  So you can then specify a
> grouping of attributes by collection: <collectionname> or by
> attribute: <attr>*. Comments?  What's the consensus here?

Again this seems to be the best way forward, lets get some opinions. 
I would argue for allowing multiple attribute types, rather than 
inventing a new collectionname that is only locally known and has to 
be broadcase to applications for them to understand it.

David

David Chadwick

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 15 Mar 2000 17:30:53 -0800

>OID is just extra clutter that actually buys you nothing.

I concur with David.  In particular, I do not think the ACI families
we conjure up tomorrow should be limited to today's attribute type
definition.  Tomorrow's ACI families may require unthought of
syntaxes and matching rules.

>want. I was raising the topic for precisely that reason.

Personally, I'd prefer attribute modify operation be control by a
single permission.  However, if the consensus is to have finer grained
control, I suggest breaking into three permissions which relate directly
to modify/add, modify/replace, and modify/delete operations.

>be broadcase to applications for them to understand it.

I think a list of attributes should be allowed and that collections
concept dropped.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 15 Mar 2000 18:44:29 -0800

Just did very quick read of the latest draft.  A few comments
and questions.

Please note that I (still) believe ldapACI should have a syntax
which requires values to conform to the BNF described by Section 6.1
of the draft and that the equality matching rule be "syntax
aware".  In particular, the equality matching rule should
treat any two ACI which have same meaning but different form
to be equal.  That is:

ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#group#cn="Dept, XYZ",c=US
ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:x#group#CN="dept, xyz",c=us
ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:x#group#cn=Dept\, XYZ,c=US
ldapACI:1.2.3.4#subtree#grant;c,s,r;attribute:xx#group#cn="Dept, XYZ",c=US
ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:1.1.1#group#cn="Dept, XYZ",c=US

where x is defined as
  ( 1.1.1 NAME ( 'x' $ 'xx' ) SUP 'name' )
should all be considerred equal.  CaseIgnoreString does cut it...
besides not handling the above, it would consider these as
being the same:

ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#KerberosID#user@REALM
ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#KerberosID#USER@realm

user != USER and REALM != realm.

Also, I think KerberosId should be generalized.  I suggest
referring to it as a UserId which allows any UTF-8 printable
string.  This maps better onto authmeth's authzid "u:".
If left as a KerberosId, it should not be a SHOULD.

The BNFs appear underspecified.  < printable string > allows
too many characters which hinder (or disallow) parsing.  A
< subject DN > should be an RFC 2253 DN string.  < oid >
should be a RFC 2252 numericoid.  

A few questions:

How does a ACL granting access to an attribute types superior affect
access the attribute type?  Ie: does granting access to 'name'
allow access to 'cn'?

I see that ACLs on attribute subtypes (cn;lang-US) are disallowed.
Is this intentional?  If so, why?  If not, any syntax issues due
to the attribute description's ';'(s) (could have more than one).

Why is ipAddress restricted to the "dotted-decimal string
representation"?  This restricts ipAddress to IPv4 addresses.
A reference to exact ipAddress form should be provided.
[I'd like wildcard support... ie: 10.*.*.* or 10.0.0.0/8
or 10.0.0.0:255.0.0.0]

Kurt

---

From: Ellen Stokes <[email-masked]>
Date: Thu, 16 Mar 2000 12:38:01 -0600

>OID is just extra clutter that actually buys you nothing.

(EJS)  A case where family OID could be useful is where the current
ldapACI attribute permission set is just extended, such as for adding
get/set/manage/use (which we removed from this draft).  However, I
see both points of view.  So, comments on this topic, please,  What's
the consensus?

---

From: [email-masked] (Mark C Smith)
Date: Thu, 16 Mar 2000 13:41:02 -0500

> see both points of view.  So, comments on this topic, please,  What's

I believe that we need extensibility, even within the ldapACI scheme. 
That could be accomplished with the family OID or with a simple version
(LDAP ACI v1, LDAP ACI v2, ...).

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?

---

From: Ellen Stokes <[email-masked]>
Date: Thu, 16 Mar 2000 12:44:54 -0600

>I think a list of attributes should be allowed and that collections

(EJS)  I'll add back the list of attributes (e.g. attribute: 
<attr>*).  However,
collection is still a valuable ease of administration concept.  I understand
that a new collection name that might only be known locally could be a
concern, but implementation could code around it to say that if it's not
understood, then it's not supported.  I'd like to retain this construct.  Any
other opinions?

---

From: Ellen Stokes <[email-masked]>
Date: Thu, 16 Mar 2000 13:11:56 -0600

Responses embedded and prefaced by (EJS)
Ellen

>should all be considerred equal.  CaseIgnoreString does cut it...

(EJS)  I agree the above examples should be case insensitive.  I'll add the
matching rule caseIgnoreString.

>should be a RFC 2252 numericoid.

(EJS)  If consensus is to retain familyOID, then, yes, it should be
specified in the BNF as <numericoid>; otherise it just goes away.

I agree that <subjectDN> in the BNF is underspecified.  It needs to
look something like:
<subjectDN> ::= <distinguishedName> |  "public" | "this" |
                <kerberosID> | <ipAddress>
where we reach agreement on how 'handle' kerberosID per your
note and Bob's response, and also define the syntax for ipAddress
(another one of your comments).  I'll handle those two in a separate
note.

>access the attribute type?  Ie: does granting access to 'name'

(EJS) No, schema hierarchy will be independent of access control
inheritance for now; we should look at this again in the future after
we get this draft to RFC.

>to the attribute description's ';'(s) (could have more than one).

(EJS) It was not our intention to disallow (I didn't even think we stated
explicitly we disallowed it).  So, I'll add wording to make sure it's
understand that it is allowed.  I'll also change some of the separators
in the BNF so there is not misunderstanding of parsing when ';' is used.
Good catch.

>[I'd like wildcard support... ie: 10.*.*.* or 10.0.0.0/8

(EJS) Another good catch.  We need to support IPv6.  I'll put out
a BNF for ipAddress to cover this.  I think we also need wildcarding, etc.
I think perhaps a good starting point here might be the BNF by Netscape
for support of ipAddress in access control.  I''m open to other suggestions
as well.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 16 Mar 2000 14:23:25 -0800

>in the BNF so there is not misunderstanding of parsing when ';' is used.

Given these two statements I would assume that an ACL for
a bare attribute type does NOT apply to subtypes of that
attribute including those distinguished only by a combination
of attribute description options.

I believe that if you allow subtyping at all, you should
allow both subtyping by 'sup' and by attribute description
options.  I personally think that ACI with subtype support
are extermely powerful, easy to manage, and (depending on
implementation) not expensive in terms of evaluation
processing, and fairly easy to implement (depending upon
server design).

To not support subtyping would place a significant burden
on directory manager to establish ACIs for all possible
subtypes.  Given the nature of some subtypes (like language
tags subtypes and combined attribute description option
subtypes), this can increase the number of ACIs needed.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 16 Mar 2000 18:17:46 -0800

>understood, then it's not supported.  I'd like to retain this construct.  Any

             The keyword "collection" indicates that the string that
             follows describes a group of attributes.  The method for
             grouping attributes is server specific.

So what if two servers hosting a cover naming context have two
very differnet means for grouping attributes?  Would not an
ACI replicated between two such servers which used a collection
understood by each, in its own way, cause the ACI to be evaluated
differently on each server?

This seems counter to "... one [an access control model] is needed
to ensure consistent secure access across heterogeneous LDAP
implementations." (p3)

How about you define a collection to be the set of attributes
allowed by an object class?   An object class, after all, is
defined (in part) as a collection of allowed attributes.

[I've been thinking of experimenting with exactly this in
OpenLDAP-devel... I'll try to find the time to implement it.]

---

From: Ellen Stokes <[email-masked]>
Date: Tue, 21 Mar 2000 07:42:16 -0600

>OpenLDAP-devel... I'll try to find the time to implement it.]

(EJS)  Kurt,  One possible solution to this (and I certainly haven't
thought this all the way through, but building on your thoughts) might
be to define a 'collection' class whose attribute is, for example, called
'list' which contains a list of the attributes in that collection.  One could
then subclass to define new collections, but this class would never be
instantiated in the directory - I would view it as a 'meta' class or schema
definition.  Is this what you had in mind?

Ellen

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 21 Mar 2000 06:50:07 -0800

>definition.  Is this what you had in mind?

I had in mind using instantiatable (and other) object classes.
I draw this suggestion from my longstanding desire to be able to
limit returned results by object class.  Lately, I've been thinking
of extending search attribute lists to accept things like:
	person;objectclass
	mailRecipient;objectclass

The presense of one of these attributes descriptions would cause
all attributes of the named object classes to be 'requested'.
The same mechanism could be applied to ACIs... the ACI would apply
to all attributes of the named object class.

As far as the 'collection' class idea, I would argue that we already
have such... 'auxiliary'.