= 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>
1. Create new iPlanet roles specific to each new EDIRrole
1. 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.