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 Overview

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.

EDIRrole General Groupings

There are currently 2900+ distinct EDIRrole values but most fall under the following general categories:

EDIRrole Identity	Permissions Granted
ADadmin	Administration of AD related attributes
EDIRadmin	Administration of any self service attribute
abideByFERPA	View FERPA protected student records
deptAdmin<unitUIDpattern>	Update unit records
emailAdmin	Administration of email related attributes
emplAdmin<unitUIDpattern>	Update people records associated with unit
helpDesk	Perform restricted account management tasks
phoneBook	Administration of phoneBook related attributes
secretaryAdmin	Administration of the secretary attribute
sponsorAccount	Sponsor directory records (includes guest account creation )
tklAdmin<TKLpattern>	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 Provisioning

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 OIT Technical Services Account Administration staff on ou=resource records and on any ou=people records not handled by ZUAUSR.

iPlanet Roles

The iPlanet roles based on EDIRrole values are divided into two categories:

• those that apply to people accessing other records
• those that apply to resource accounts accessing other records.

The iPlanet roles that govern people's access require that the person requesting access 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. The following example shows the controls for permission to administer EDIR.

$ 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