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

Re: Attribute groupings



I agree. It doesn't play well in a hosting environment. An attribute "X" has
different security requirements  to different domains.  Grouping them doesn't buy
any big advantage.

For ease of administration - let the UI handle it .
Able to specify each individual attribute seems to me more flexible.
That has been the experience for us.

Thanks,
/prasanta
==========================

David Ward wrote:

> I am not convinced any advantages gained by being able to group an object's attributes outweigh the added complexities.  If we allow attribute groups, how are the groupings defined and do they apply to all objects of a particular class (attribute group1 applies to the object class class inetOrgPerson) or do they apply to individual instances of an object class?  If they are to apply to all instances of an object class, we probably need a way to store this information in the schema.  If they apply to only one instance of an object, I see no advantages.  If you are going to define a group of attributes, why not just call out the attributes in regular aci(s).
>
> There already is a reserved keyword, "[all]".  This provides an easy mechanism to define generic rights which apply to the group of all attributes and then specific rights can be applied for individual attributes as needed.
>
> David Ward
> dsward@novell.com
>
> >>> <djbyrne@us.ibm.com> 10/25/99 3:10:46 PM >>>
>
> Within the BNF, we have a syntax for grouping attributes;
>
> < attrs > ::= [ < attributeString>
>                          + [ ',' + < attributeString > ] * ]
>
>   The attributeString is an attribute Name (defined to be a
>              printable string).  If the string refers to an attribute
>              not defined in the given server's schema, the server
>              SHOULD report an error.
>      ....
>              Multiple attributeStrings can be listed after any given
>              permission set; for instance, "r,w ; attribute1,
>              attribute2". This means that if the server supports a
>              attribute aggregation mechanism, attribute1 and
>              attribute2 should be considered to be part of the same
>              group. If the server does not support a grouping
>              mechanism, the permission set applies independently to
>              attribute1 and attribute2. For servers that do not
>              support attribute grouping, "grant ; r,w ; attribute1,
>              attribute2" results in the same operations as "grant ;
>              r,w; attribute1$grant; r,w; attribute2"
>
> While this definition allows aggregation of attributes into groups, it does
> not provide an easy mechanism for doing the reverse; setting an aci that
> applies to a group of attributes, and allowing the aci to apply to all
> attributes within that grouping that already exists. The ability to do this
> is very important for ease of administration as the number of attributes
> within the directory increases.
>
> There are two possibilities for adding this function to the draft;
> a) The attribute string could refer to either an attribute or an attribute
> grouping.  This approach could make it difficult to distinguish between
> attributes and groupings of attributes. It would also mean that the
> attribute names can not be re-used as a grouping name.
> b) Add to the BNF to support a grouping syntax;
>
> Thought / Comments ?
>
> Debbie
>
> INet: djbyrne@us.ibm.com
> Lotus Notes : djbyrne@ibmus
> Phone: (512)838-1930 ( T/L 678 )

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature