= EDIRrole and Associated iPlanet Roles =
   Original author:  Beth Mercer - 20081103              

''Note:'' Though out this document are references to ldap_*<Inst> commands.  Those are 
simply scripted invocations of the associated ldap* utilities that make it possible 
to search the directory, and to add, modify and delete directory data using the 
Directory Manager credentials.  The ldap_*<Inst> scripts can be found on the "e" 
boxes under ~iplanet/local/ldap/scripts.

EDIRrole is a locally defined attribute used to make attribute based authorization 
decisions within EDIR, AUTHSERV, their UPDATE back end and at the directory  
level itself.  Within the web gateways, the presence or absense of an EDIRrole 
value determines whether or not a user is allowed to interact with an administrative
form.  At the UPDATE back end, the presence or absense of an EDIRrole value 
determines whether or not a restricted function relying on agent credentials rather 
than user credentials will be performed at the request of a particular user.  At the 
directory level, EDIRrole values are referenced by iPlanet roles which are associated 
with ACIs that provide update access to groups of directory records.

EDIRroles are given meaning by the web gateways, backend and directory roles 
that reference them.  

There are currently 2900+ distinct EDIRrole values but most are flavors of the 
following:

	ADadmin		# the ability to administer AD related attributes
	EDIRadmin	# the ability to administer any self service attribute
	abideByFERPA	# the ability to see FERPA protected student records
	deptAdmin<unitUIDpattern>	# the ability to update unit records
	emailAdmin			# the ability to administer email related attributes
	emplAdmin<unitUIDpattern>	# the ability to update people records associated with unit
	helpDesk		# the ability to perform restricted account management tasks
	phoneBook		# the ability to administer phoneBook related attributes
	secretaryAdmin		# the ability to administer the secretary attribute 
	sponsorAccount		# the ability to sponsor directory records (includes guest account creation)
	tklAdmin<TKLpattern>	# the ability to update people records associated with TKL

The greatest variety exists in the deptAdmin* emplAdmin* and tklAdmin* EDIRrole 
values.  Those roles are scoped to allow access to a single unit/TKL or a group of 
units/TKLs which roll up to a common record.

EDIRrole values are provisioned on ou=people records by the ZUAUSR application when 
it processes super classes that contain EDIR related grants.  Since ZUAUSR is an 
application that supports provisioning of administrative access only to employee 
accounts (and a handful of exceptions), EDIRrole values must be manually provisioned 
by TSAA staff on ou=resource records and on any ou=people records not handled by 
ZUAUSR.

The iPlanet roles based on EDIRrole values come in two flavors: those that apply to 
people accessing other records and those that apply to resource accounts accessing 
other records.  The iPlanet roles that govern people's access require that the person 
doing the accessing have a current job assignment.  That helps insure that users 
who leave the university do not retain viable directory access even if account 
administration practices do not result in the timely revocation of administrative 
accesses.

	iplanet@egegik> cat role.EDIRadminRole.ldif         
	dn: cn=EDIRadminRole,ou=people,dc=alaska,dc=edu
	objectclass: top
	objectclass: LDAPsubentry
	objectclass: nsRoleDefinition
	objectclass: nsComplexRoleDefinition
	objectclass: nsFilteredRoleDefinition
	cn: EDIRadminRole
	nsRoleFilter: (&(EDIRROLE=*)(EDIRrole=EDIRadmin)(eduPersonAffiliation=Employee)(assignmentCount=*)(!(assignmentCount=0)))
	Description: filtered role for entities administering EDIR
	
Resource credentials on the other hand are granted to applications not people and 
applications do not have current job assignments so the assignment criteria is omitted:

	iplanet@egegik> cat role.EDIRadminRole.resource.ldif
	dn: cn=EDIRadminRole,ou=resource,dc=alaska,dc=edu
	objectclass: top
	objectclass: LDAPsubentry
	objectclass: nsRoleDefinition
	objectclass: nsComplexRoleDefinition
	objectclass: nsFilteredRoleDefinition
	cn: EDIRadminRole
	nsRoleFilter: (&(EDIRROLE=*)(EDIRrole=EDIRadmin))
	Description: filtered role for resource entities administering EDIR

iPlanet roles are created and deleted as follows:

	iplanet@egegik> ldap_deleteTest 
	inst: test
	port: 13338
	
	
	ldapdelete: started Mon Nov  3 16:35:08 2008
	
	ldap_init( egegik, 13338 )
	ldaptool_getcertpath -- /e01/iplanet/servers/alias/slapd-egegiktest-cert8.db
	ldaptool_getkeypath -- /e01/iplanet/servers/alias/slapd-egegiktest-cert8.db
	ldaptool_getdonglefilename -- (null)
	cn=EDIRadminRole,ou=resource,dc=alaska,dc=edu
	deleting entry cn=EDIRadminRole,ou=resource,dc=alaska,dc=edu
	entry removed
	<ctrl+d>

	iplanet@egegik> ldap_addTest -f role.EDIRadminRole.resource.ldif             
	inst: test
	port: 13338
	
	
	ldapmodify: started Mon Nov  3 16:35:25 2008
	
	ldap_init( egegik, 13338 )
	ldaptool_getcertpath -- /e01/iplanet/servers/alias/slapd-egegiktest-cert8.db
	ldaptool_getkeypath -- /e01/iplanet/servers/alias/slapd-egegiktest-cert8.db
	ldaptool_getdonglefilename -- (null)
	add objectclass:
	        top
	        LDAPsubentry
	        nsRoleDefinition
	        nsComplexRoleDefinition
	        nsFilteredRoleDefinition
	add cn:
	        EDIRadminRole
	add nsRoleFilter:
	        (&(EDIRROLE=*)(EDIRrole=EDIRadmin))
	add Description:
	        filtered role for resource entities administering EDIR
	adding new entry cn=EDIRadminRole,ou=resource,dc=alaska,dc=edu
	modify complete

iPlanet roles created for ou=people,dc=alaska,dc=edu and ou=resource,dc=alaska,dc=edu 
in a directory instance on one server are automatically replicated to the same directory 
instance on all other servers.  That is because roles are simply another form of 
directory data and those branches of the directory are configured for automatic 
replication of directory data changes.

# eof