Grouper Developers Forum

[Tom Barton <>]

Thanks for taking that step!

I understand your choice for presenting the VIEW and READ privileges in 
both DN and non-DN forms, as it will enable both the LDAP DSA and 
applications using ldap groups to try to respect those restrictions.

What use case do you have for exposing the ADMIN priv? As a pointer to 
who is responsible for the group?

I'm unsure about the customType and customTypeFieldOrList attributes. If 
a grouper group has a custom type whose custom attributes should be 
exposed in ldap, perhaps there should be a corresponding ldap 
objectclass that is applied to those groups and declares appropriate 
ldap attributes.

More comments below...

Tom

Arnaud Deman wrote:
> Hi,
>
> I come back with the question of ldappc and grouper privileges (started 
> in the grouper-users list).
>
> We have started to work on an extension of the ldappc schema for this.
> Our approach was to extend the existing class and to keep the logic :
> For each privilege there is one attribut for the dn and one attribute 
> for the uid.
>
> This is oly an starting point and there are already points which I'm not 
> sure :
> - To use the class eduMember instead of creating a new one,

Extending eduMember is not a bad idea, though at this point perhaps 
we're talking about a grouper-specific objectclass and not a generic 
membership objectclass. But that's merely semantics - I can't think of a 
principle that would tell us when to extend this objectclass versus 
create a new one.

> - The oids to use for the attributes,

If we stay with eduMember then the OID assignments can indeed stay 
within MACE's OID arc, as with eduMember. Probably the values you wrote, 
though I'd have to go back and double-check.

> - The use of the DN syntax for the dn attributes, because of the 
> comparison,
> - The attribute displayName comes from the inetorgperson schema,

And use "o" for group displayNames, I suppose, from groupOf[Unique]Names.

> - I didn't put the update privilege, because I believe it is only 
> usefull in Grouper (like the optin and optout privileges).
>
> Thanks,
> Arnaud.
>
>
> Arnaud Deman a écrit :
> > Tom Barton a écrit :
> > > > I don't thik we will use this approach mainly for two reasons:
> > > > - The privileges mecanism of Grouper was one of our motivation in 
> > > > our choice of using Grouper and I would like to use it from all the 
> > > > access points of the groups.
> > > > - We will delegate the administration of some groups to the local 
> > > > administrators (who are teachers) and I don't want to complicate the 
> > > > groups management.
> > >
> > > Good point.
> > >
> > > I've created enhancement request 
> > > <https://bugs.internet2.edu/jira/browse/MCO-22> to track this.
> > >
> > > > > In addition, there would need to be an LDAP objectclass created 
> > > > > that contains the appropriate attributes in which to list Subjects 
> > > > > from those lists. Have you already created one? 
> > > > Not yet, because I wondered if there is standard class/attribute to 
> > > > do that. In fact this was my next question :-) .
> > > Hmm. Might you be interested to create one and put it on the list for 
> > > comments?
> > >
> > > Tom
> > Ok Tom, I'll do it when I start working on it.
> >
> > Arnaud.

# *** Start eduMember ###
#

#
# An auxiliary object class, "eduMember," is a convenient container
# for an extensible set of attributes concerning group memberships.
# At this time, the only attributes specified as belonging to the
# object class are "isMemberOf" and "hasMember."
#
attributetype ( 1.3.6.1.4.1.5923.1.5.1.1
        NAME 'isMemberOf'
        DESC 'identifiers for groups to which containing entity belongs'
        EQUALITY caseExactMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributetype ( 1.3.6.1.4.1.5923.1.5.1.2
        NAME 'hasMember'
        DESC 'identifiers for entities that are members of the group'
        EQUALITY caseExactMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributetype ( 1.3.6.1.4.1.5923.1.5.1.3
        NAME 'viewer'
        DESC 'DN of entities that can view the group'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

attributetype ( 1.3.6.1.4.1.5923.1.5.1.4
        NAME 'hasViewer'
        DESC 'identifiers for entities that can view the group'
        EQUALITY caseExactMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributetype ( 1.3.6.1.4.1.5923.1.5.1.5
        NAME 'reader'
        DESC 'DN of entities that can read the group'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

attributetype ( 1.3.6.1.4.1.5923.1.5.1.6
        NAME 'hasReader'
        DESC 'identifiers for entities that can read the group'
        EQUALITY caseExactMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributetype ( 1.3.6.1.4.1.5923.1.5.1.7
        NAME 'administrator'
        DESC 'DN of entities that can administrate the group'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

attributetype ( 1.3.6.1.4.1.5923.1.5.1.8
        NAME 'hasAdministrator'
        DESC 'identifiers for entities that can administrate the group'
        EQUALITY caseExactMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributetype ( 1.3.6.1.4.1.5923.1.5.1.9
        NAME 'customType'
        DESC 'Custom type of the group'
        EQUALITY caseExactMatch
    SINGLE-VALUE
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attributetype ( 1.3.6.1.4.1.5923.1.5.1.10
        NAME 'customTypeFieldOrList'
        DESC 'Field or list associated to the custom type of the group'
        EQUALITY caseExactMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )


objectclass ( 1.3.6.1.4.1.5923.1.5.2.1
        NAME 'eduMember'
        AUXILIARY
        MAY ( displayName $
          isMemberOf $ hasMember $
          viewer $ hasViewer $
          reader $ hasReader $
          administrator $ hasAdministrator $
          customType $ customTypeFieldOrList
           )
        )