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