Subject: Re: Considering Attribute Subtypes during ACL evaluation

From: Mark Wahl <[email-masked]>
Date: Mon, 02 Oct 2000 10:59:59 -0500

Prasanta Behera wrote:
> 
> Currently  the netscape/iPlanet DS ACL supports a attribute inheritance of
> subtypes e.g. if you allow access to
> "cn", it automatically means { cn, cn;* }
> 
> However, it is much harder to map "name" to "cn, sn".
> Why can't this be a UI thing? Why does it have to be
> declarative in the ACL syntax itself. It will be nice if it
> can be supported but I don't see a big reason ...

The schema and access control may be managed by different individuals.  One
can envisage a user being permitted to define a subtype of an attribute but 
not having the ability to modify access control rights.  As there are no 
rights to the new attribute, it might disappear. 

Mark Wahl
Sun Microsystems, Inc.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 30 Sep 2000 11:38:38 -0700

At 07:39 AM 9/30/00 -0700, Prasanta Behera wrote:
>Currently  the netscape/iPlanet DS ACL supports a attribute inheritance of subtypes e.g. if you allow access to 

I would say that server dependent.  If your server has schema
aware ACL evaluation (which I dare say is a must if you intend
to handle alternative naming of attribute types), then handling
subtyping is no big deal.

Of course, subtyping in LDAP is completely optional.  I would
argue that subtyping within ACLs should likewise be optional.

---

From: sanjay jain <[email-masked]>
Date: Fri, 06 Oct 2000 15:00:27 -0700

"Kurt D. Zeilenga" wrote:

[snip]

> However, given that subtyping is optional in LDAPv3,

Kurt
   Could you please point to the text in RFC 2251 (or
   any other LDAP RFC) which explicitly states that
   subtyping is optional in LDAPv3.  I just want to confirm.

thanks
sanjay

> one
> could argue it's best to leave subtyping within ACLs as
> being optional.
>
> Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Oct 2000 16:17:32 -0700

>   subtyping is optional in LDAPv3.  I just want to confirm.

I believe it's implicit in the following statements:

3.2.2:
   Servers which follow X.500(93) models SHOULD implement subschema
   using the X.500 subschema mechanisms, and so these subschemas are not
   ordinary entries.  LDAP clients SHOULD NOT assume that servers
   implement any of the other aspects of X.500 subschema.

The first sentence implies that servers may not follow X.500(93).

3.3:
   LDAP can be mapped onto any
   other directory system so long as the X.500 data and service model as
   used in LDAP is not violated in the LDAP interface.

The interface is not violated if subtyping is not supported.

---

From: sanjay jain <[email-masked]>
Date: Mon, 09 Oct 2000 10:08:08 -0700

> The interface is not violated if subtyping is not supported.

    IMO, its very hard to interpret based on above info that subtyping is
    optional in LDAP V3.

    Looks like if an LDAP client sends a search request with
    filter (name=xyz) and gets back objects which satisfy exactly
    this filter then it is not easy for the client to know whether the
    server does not support subtypes or there are no objects (in same
    scope etc..) which satisfy (cn=xyz) or (sn=xyz) types of filters.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 09 Oct 2000 17:27:38 -0700

>    IMO, its very hard to interpret based on above info that subtyping is

Jim pointed out that "RFC 2256, Section 5.42" makes an explicit
statement in regard to subtyping support being elective.

>    scope etc..) which satisfy (cn=xyz) or (sn=xyz) types of filters.

Feature discovery through trial and error is always problematic.
A better mechanism, such as one of those previously proposed on
this list, should be formalized.