EDUISMEMBEROF and Associated Group Records

Original author: Beth Mercer - 20081103

Note: Originally, the isMemberOf attribute of the eduMember objectClass was used for Group Memberships. That attribute became intricately bound into the inner workings of the SUN LDAP product. For that reason, the following documentation now refers to isEduMemberOf, the attribute that is used by University of Alaska to establish membership.

The eduIsMemberOf is an attribute of the eduMember objectClass. At creation, the eduMember objectClass is granted to every directory record defined by 'people' organizational unit (ou=people). Provisioning isMemberOf is based upon individual group memberships that are in turn used by external applications to make authorization based decisions.

Note: While eduIsMemberOf 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 eduIsMemberOf value that does not match any existing group name.

Creating Group Records

The mechanism by which group organizational unit (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.

Provisioning Group Membership

The mechanism by which eduIsMemberOf values are provisioned is presently ZUAUSR. The limitation with that tool is that ZUAUSR is an application that performs provisioning for administrative users which historically have been only employees and select vendors.

Provisioning Strategies Not Reliant on ZUAUSR

If/when the use of group records and the eduIsMemberOf 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 eduIsMemberOf provisioning.

That can be accomplished as follows:

1. Create new EDIRrole values specific to particular applications/provisioning processes
   • EDIRrole: groupAdmin<pattern>
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 <pattern>

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=<iPlanet LDAP server>);)

ACI Snippet for eduIsMemberOf 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=<iPlanet LDAP server>);)

Pattern of Group Names and eduIsMemberOf Values to Which ACIs Apply

cn=appusers:AppA:*,ou=group,dc=alaska,dc=edu

In the example, the assumption is still that group and eduIsMemberOf 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 eduIsMemberOf maintenance for their own pattern of group names, then iPlanet roles should be created that rely on a specific eduIsMemberOf values rather than EDIRrole values. Then who ever was granted a key eduIsMemberOf value could in turn grant other users the same eduIsMemberOf value, there by delgating !group/eduIsMemberOf 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/eduIsMemberOf for specific applications.