[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Considering Attribute Subtypes during ACL evaluation

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 ...

thanks,
/prasanta

hahnt@us.ibm.com wrote:

 
Jim,

Good question!

I know that implementing access control such that attribute inheritance were taken into account would definitely be harder, but I feel that attribute inheritance SHOULD be considered during access control checks.

Thus, if some entity is granted read and write privileges to 'name', then they should be allowed the same privileges to 'cn', 'sn', and 'cn;lang-en'.  (unless overidden by another permission that disallows such access).

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

To:        <ietf-ldapext@netscape.com>
cc:        "Duane Buss" <DBuss@novell.com>
Subject:        Considering Attribute Subtypes during ACL evaluation
 
 
 

Are attribute subtypes considered when calculating access  control information? In other words, if I have read permission to the "name"  attribute, does that automatically give me read permission to sn, cn, givenName,  etc?

I can't find any coverage of this in X.511 or the latest ACL  draft. Due to the lack of anyone talking about it, my assumption is that, no,  permissions do not flow down attribute inheritance chains, they must be  explicitly stated for each attribute.

Of course with LDAP, this brings up the question of whether  they apply to attribute type options. It seems to make sense, under most  circumstances, to apply them in this case. Oh, what a world - what a  world.