Subject: Re: I-D ACTION:draft-ietf-ldapext-acl-model-06.txt

From: "Haripriya S" <[email-masked]>
Date: Thu, 20 Jul 2000 05:29:19 -0600

In the current model of ACL I cannot find how to actually set ACLs for a 'to be created entry' based on its objectClass. For example, I may want a set of ACLs to be present for all the objects of type inetorgperson, to expose certain attributes by default to even an unauthenticated user. It would help in this case, if I have mechanism's to set ACLs for the objectclass itself, so that any entry of that class created automatically gets these ACLs. The other alternative would be for me to set these ACLs at one parent with scope subtree and let all the entries under that parent inherit these ACLs. But this would not let me distinguish by objectclass ( I may want to expose cn for inetorgperson but not for residentialperson by default). Does anybody have ideas on this?

Thanks and Regards,
Haripriya

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Fri, 21 Jul 2000 16:45:33 +0200

Haripriya,

You are right that there is no way to do this in the current draft.
I think it's a useful feature and should probably be added.

It involves adding the capability to specify an LDAP filter (restricted
to objectclass only ?) to the ldapACI.

Rob.

>  In the current model of ACL I cannot find how to actually set ACLs for a 'to be created
>  entry' based on its objectClass. For example, I may want a set of ACLs to be present for all
>  the objects of type inetorgperson, to expose certain attributes by default to even an
>  unauthenticated user. It would help in this case, if I have mechanism's to set ACLs for the
>  objectclass itself, so that any entry of that class created automatically gets these ACLs.
>  The other alternative would be for me to set these ACLs at one parent with scope subtree and
>  let all the entries under that parent inherit these ACLs. But this would not let me
>  distinguish by objectclass ( I may want to expose cn for inetorgperson but not for
>  residentialperson by default). Does anybody have ideas on this?
>
>  Thanks and Regards,
>  Haripriya
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 Jul 2000 07:59:49 -0700

Rob,

Instead of a filter restricted to object classes, why not
reintroduce collections concept, but define collections
as being a collection of object classes?  The ACI would apply
to all attributes allowed by any of the object classes within
the collection.

Kurt

At 04:45 PM 7/21/00 +0200, Rob Byrne - Sun Microsystems wrote:
>  
>Haripriya, 
>
>You are right that there is no way to do this in the current draft.  I think it's a useful feature and should probably be added. 
>
>It involves adding the capability to specify an LDAP filter (restricted to objectclass only ?) to the ldapACI. 
>
>Rob. 
>>

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Fri, 21 Jul 2000 17:30:59 +0200

Kurt,

I think the question was rather how to make an aci grant access as a
function of the value of the objectclass attribute in it's entry. In the
example, both objectclasses allow the cn attribute but we want the aci
to apply in one case but not the other.

>       residentialperson by default).
>

So, I don't see how your suggestion allows that distinction to be made.

Rob.

"Kurt D. Zeilenga" wrote:

>> It involves adding the capability to specify an LDAP filter
>> (restricted to objectclass only ?) to the ldapACI.
>>
>> Rob.
>>
>> >
>> >

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 Jul 2000 08:48:18 -0700

At 05:30 PM 7/21/00 +0200, Rob Byrne - Sun Microsystems wrote:
>I think the question was rather how to make an aci grant access as a function of the value of the objectclass attribute in it's entry.

Fair enough.

>In the example, both objectclasses allow the cn attribute but we want the aci to apply in one case but not the other.

Okay.  Content based ACIs... hmmm.... seems this might cause a few wrinkles
(or at least add a lot of complexity).

---

From: "David Chadwick" <[email-masked]>
Date: Sun, 23 Jul 2000 09:26:54 +0100

Date forwarded: 	Fri, 21 Jul 2000 07:46:13 -0700 (PDT)
Date sent:      	Fri, 21 Jul 2000 16:45:33 +0200
From:           	Rob Byrne - Sun Microsystems <[email-masked]>
Organization:   	Sun Microsystems
Copies to:      	Haripriya S <[email-masked]>, [email-masked]
Subject:        	Re: filters in ldapACI (WAS Re: I-D 
	ACTION:draft-ietf-ldapext-acl-model-06.txt)
To:             	[email-masked]
Forwarded by:   	[email-masked]

> 
> Haripriya,
> 
> You are right that there is no way to do this in the current draft. I
> think it's a useful feature and should probably be added.
> 

This is precisely what X.500 ACI has as a feature. Only in this case 
the object class filter is not part of the ldapACI attribute but part of 
the subtree specification attribute that accompanies it in the 
subentry. (HOwever the two are synonomous. They are just 
different ways of structuring the same information i.e. one complex 
attribute vs two simpler attributes that keep their relationship by 
being together in a subentry. My familier of entries ID further 
extended this model to be fully general for any entry)

David

> Rob.
> 
> >  In the current model of ACL I cannot find how to actually set ACLs
> >  for a 'to be created entry' based on its objectClass. For example,
> >  I may want a set of ACLs to be present for all the objects of type
> >  inetorgperson, to expose certain attributes by default to even an
> >  unauthenticated user. It would help in this case, if I have
> >  mechanism's to set ACLs for the objectclass itself, so that any
> >  entry of that class created automatically gets these ACLs. The
> >  other alternative would be for me to set these ACLs at one parent
> >  with scope subtree and let all the entries under that parent
> >  inherit these ACLs. But this would not let me distinguish by
> >  objectclass ( I may want to expose cn for inetorgperson but not for

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

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: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 23 Jul 2000 11:59:35 -0700

At 09:26 AM 7/23/00 +0100, David Chadwick wrote:
>being together in a subentry.

Though both X.500 subentry and ldapACI offer sophisticated
scoping specification mechanisms, the X.500 subentry is a general
mechanism which can be applied to numerous features.  That
is, a server can implement the subentry complexity once
and then apply it to multiple features.  ldapACI's mechanism
is specific to the feature it provides.   Other attributes
would have to define it's own scoping mechanisms (or use
X.500's subentry provided mechanism).

There are, of course, a number of differences in the actual
scoping mechanisms.

Also, ldapACI could be scoped using ldapACISubentry (or
X.500 subentry for that matter).  The specification of such is
stated as being out of scope of the ACM I-D, which is wise.
The LDAPsubentry I-D does not define any scoping semantics
and appears to only provide a generic container for operational
information.  But that's another thread.

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 25 Jul 2000 14:53:07 +0100

Kurt said

> mechanism which can be applied to numerous features.  That is, a
> server can implement the subentry complexity once and then apply it to
> multiple features.  ldapACI's mechanism is specific to the feature it
> provides.   Other attributes would have to define it's own scoping
> mechanisms (or use X.500's subentry provided mechanism).
> 

Kurt
I am not sure whether you are arguing for or against the X.500 
subentry type of mechanism in your statements above? Or was it 
just an observation?

David

David Chadwick

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 25 Jul 2000 07:55:05 -0700

>subentry type of mechanism in your statements above? Or was it 

I making a argument for a common scoping mechanism that can be
applied to multiple attributes.  I believe having per attribute
scoping mechanisms, such as ldapACI's subtree mechanism, is a
bad idea.

Kurt