Re: attirbute collections

[Rob Byrne - Sun Microsystems <Robert.Byrne@france.sun.com>]

Hi All,

I'm not convinced of the need to define collections seperate from the ldapACI
itself....anyone like to remind me of the good reasons for that ?

I think that allowing lists of attributes to appear in the ldapACI does not
unduly encumber it and avoids the location/distribution questions that arise
when the collection is ex-ldapACI.

I do think that allowing an Objectclass to appear in such a list of attributes
would be good, which is making use of "collections" that are already defined
in the Directory.  At least then the distribution of collections becomes a
subset of the schema distribution problem, rather than adding to it.

Debbie, some questions for you:

. If you look at the way the LDUP guys have defined the list of attributes
that are "in" or "out" for replication they use one attribute to contain a
list of attributenames (an AttributeDescriptionList)---maybe we should be
doing it the same way just for "sameness" ?
( http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-01.txt , section
6.2.2)

. as I said above, I think it is useful to be able to refer to the list of
attributes in an Objectclass so maybe memberAttributes should be allowed to
conatin an Objectclass name ?

. Maybe this is a more general issue but do you think it's wise to try to
mandate tight consistency of these collections with the Schema ? ("Any
attribute listed in
memberAttribute must be defined in the schema.").  That's not so flexible and
ensuring that kind of consistency is hard.

Rob.

djbyrne@us.ibm.com wrote:

> One of the items which was deemed as 'needs further discussion' during the
> sessions was the idea of a collection. There was much concern over the
> interoperability of collections. The following is a proposal for how
> collections could be defined in an interoperable manner.
>
> Collections of attributes would be described by an object in the directory
> with a particular objectclass 'attributeCollection'.
> The objectclass has two mandator objects : a collectionName, and
> memberAttributes.  This is similar to the group concept which contains
> memberDNs instead of attribute Names. Any attribute listed in
> memberAttribute must be defined in the schema.
>
>           class attributeCollection
>                MUST (
>                     collectionName       printableString single-valued
> /* name of the collection */
>                     memberAttributes     printableString  multi-valued
> /* name of attrs in the collection */
>                     )
>                MAY (<pick some that make sense>)
>
> This class is instantiated in the DIT and can then be used within the ldap
> ACI by using the collection name. If one gives permission to the
> collection, one is essentially giving that permission to all attributes
> within the collection.
>
> There are several issues that would need further definition; some of which
> have already been mentioned.
>
> The first is whether an attribute can belong to more than one collection,
> and if so, what is the behavior.  My instinct is to treat this in the same
> manner in which we treat the different subject Types. So, the more specific
> overrides the less specific. Therefore, if an attribute is specified, and
> the attribute belongs to a collection, the attribute permissions are used
> instead of the collection permissions. If the attribute is not specifically
> listed within the aci, then the collection permissions are used. If the
> attribute exists in more then one collection, the permissions are unioned,
> with the same grant - deny precedence rules which we have already
> discussed.
>
> The second issue I see is in using the collectionName within the ldapACI.
> The problem that could arise is that this attribute name is not necessarily
> unique. Any enforcement of uniqueness would be at an application level, not
> the directory level.  The way to force this at the directory would be the
> use collectionName as the RDN value, and state that collections must be
> defined in a specific location; for instance, they must be children of the
> schema node which is enforced in that portion of the DIT.  Therefore,
> because the attribute is used as the RDN value, uniqueness can be
> guaranteed.
>
> Comments / suggestions welcome !
>
> Thanks,
>
> Debora Byrne
> Manager Secure Way Directory Config / User Interface
> INet: djbyrne@us.ibm.com
> Phone: (512)838-1930 ( T/L 678 )