20081103 elm ISMEMBEROF and Associated Group Records isMemberOf is an attribute of the eduMember objectClass. The eduMember objectClass is granted to every ou=people directory record when created. isMemberOf is provisioned with individual group memberships that are in turn used by external applications to make authorization based decisions. isMemberOf values are expected to tie to ou=group records of the same name although there is currently no mechanism within the directory that forces that relationship. So, it is currently possible to provision an isMemberOf value that matches no group name. The mechanism by which ou=group records are created is the AUTHSERV Seed Group page: https://authserv.alaska.edu/cgi-bin/seed_group That CGI script creates both the directory group record as well as a registry record to track the group. The mechanism by which isMemberOf values are provisioned is presently ZUAUSR. However, ZUAUSR is an application that performs provisioning for administrative users which historically have been only employees and select vendors. If/when the use of group records and the isMemberOf attribute is extended to serve a population of non-employees, then other mechanisms for provisioning will need to be created. When that comes to pass, it is recommended that different consituent groups be protected from each other's activities by creating security objects that scope access to group record creation and isMemberOf provisioning. That can be accomplished as follows: 1) Create new EDIRrole values specific to particular applications/provisioning processes EDIRrole: groupAdmin 2) Create new iPlanet roles specific to each new EDIRrole 3) Create ACIs tied to the new iPlanet roles in which the scope of the access is defined in a targattrfilters clause which limits access to group names beginning with EXAMPLE: # EDIRrole value groupAdminAppA #iPlanet role dn: cn=groupAdminAppARole,ou=people,dc=alaska,dc=edu objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: groupAdminAppARole nsRoleFilter: (&(EDIRROLE=*)(EDIRrole=groupAdminAppA)(eduPersonAffiliation=Employee)(assignmentCount=*)(!(assignmentCount=0))) Description: filtered role for entities allowed to define groups and provision membership for AppA # ACI snippet for group record creation/deletion (targattrfilters="add=cn:(cn=appusers:AppA:*), del=cn:(cn=appusers:AppA:*)") allow (compare,read,write,search) (roledn="ldap:///cn=groupAdminAppARole,ou=people,dc=alaska,dc=edu" and (ip="137.229.9.17 || 137.229.9.68 || 137.229.9.71 || 137.229.9.75"));) # ACI snippet for isMemberOf updates (targattrfilters="add=isMemberOf:(isMemberOf=cn=appusers:AppA:*), del=isMemberOf:(isMemberOf=cn=appusers:AppA:*)") allow (compare,read,write,search) (roledn="ldap:///cn=groupAdminAppARole,ou=people,dc=alaska,dc=edu" and (ip="137.229.9.17 || 137.229.9.68 || 137.229.9.71 || 137.229.9.75"));) # pattern of group names and isMemberOf values to which ACIs apply cn=appusers:AppA:*,ou=group,dc=alaska,dc=edu In the example, the assumption is still that group and isMemberOf maintenance for AppA is being delegated to a univeristy employee who's account can be provisioned via ZUAUSR. If instead responsibility is to be delegated to an application, then the iPlanet role needs to be stuctured for use by ou=resource records. Should applications have a need to independently delgate group and isMemberOf maintenance for their own pattern of group names, then iPlanet roles should be created that rely on a specific **isMemberOf** values rather than EDIRrole values. Then who ever was granted a key isMemberOf value could in turn grant other users the same isMemberOf value, there by delgating group/isMemberOf maintenance authority. NOTE: EDIRrole values can not be used to facilitate delegation of delegated authority as only users with EDIRadmin can provision EDIRrole values and EDIRadmin will **NOT** be granted to individuals managing group/isMemberOf for specific applications. # eof