= EDIRrole and Associated iPlanet Roles = Original author: Beth Mercer - 20081103 ''Note:'' Though out this document are references to ldap_* 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_* 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 || Update unit records || || emailAdmin || Administration of email related attributes || || emplAdmin || 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 || 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 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