EDIR/AUTHSERV Access Control
Original author: Beth Mercer - 20081103
See also:
Because EDIR/AUTHSERV are comprised of a loosely coupled set of CGI scripts (the web pages), stored procedures and batch processes (the Oracle registry) and iPlanet directory, restrictions on access control are implemented in a number of ways.
Directory ACIs and Schema
The primary mechanism for restricting access are the iPlanet directory ACIs. Those ACIs dictate who may READ, WRITE, SEARCH and COMPARE directory data. No matter what mechanism is used to access directory data, the underlying ACIs limit what is possible.
However, the directory ACIs as currently established do not cover all functions resulting in directory updates. For instance, there are currently no ACIs that make it possible for a credentialed user to create a directory record whether it be a guest or resource account, routing or department record, or group record. Until such time as sufficiently restrictive ACIs are created, the Directory Manager credentials are utilized to perform select functions.
The directory schema also plays a role in access control. No data can be injected into or updated in the directory unless the attribute/object being referenced is defined in the directory schema.
EDIRrole Attribute and iPlanet Roles
EDIRrole is a locally defined attribute used in the definition of iPlanet roles which in turn are used to scope directory ACIs. Each EDIRrole is associated with a specific type of administrative access; the ability to reset passwords, create guest accounts, update department records, etc. EDIRrole values are in some cases also used to scope a type of access (ability to update some department records but not others).
NOTE: EDIRrole grants are managed via normal administrative channels (ZUAUSR).
Web Gateway CGI Scripts
In addition to being used in the definition of iPlanet roles which are in turn used to scope directory ACIs, EDIRrole grants are utilized by the EDIR/AUTHSERV web gateway CGI scripts to control access to (display of) various web pages. This allows the web pages to reject access upfront without first attempting an action in the directory.
Having a web page check EDIRrole grants prior to performing an action is particularly important for those pages that rely on Directory Manager credentials rather than the credentials of the users requesting the action. Only individuals granted a particular EDIRrole are allowed to trigger the execution of restricted functions performed by Directory Manager.
Web gateway CGI scripts also rely on a special mapping of directory attributes that determine whether or not a particular attribute will be presented in an update page. This helps to reduce the number of complaints by users that say "I tried to change <blah> but I got an error saying I did have the authority to make the change".
Update Back End
All updates of self service attributes are ultimately processed by a back end web site designed for the sole purpose of processing update requests. That update back end, which is closest to directory data, also utilizes EDIRrole grants to limit access to restricted functions. This insures that even if a particular web page fails to limit access, the back end processes requests only from users with the authority to make the request.
Being closest to the directory data, the update back end is one of two points at which business rules are most appropriately enforced and is therefore a mechanism for restricting access. The other point where business rules are appropriately enforced is the Oracle registry.
Oracle Registry
The Oracle registry is the primary mechanism by which business rules are enforced during directory updates and is therefore a mechanism for restricting access. During the two step update process for self service directory attributes, attribute changes are first submitted to the Oracle registry. If during the enforcement of business rules the update is rejected, then no further action is taken and the update is denied.
In September of 2008, three attributes were excluded from the process of two step updates and so now bypass the Oracle registry: uakUserPassword, uakSecQuestion and uakSecResponse. The business rules formerly enforced by the Oracle registry are now enforced by a separate application, ELMO.
########################################################
LEGACY CHANGE HISTORY - NOTE: All subsequent changes are recorded in TracWiki
########################################################
20081031 elm corrected typo 20081103 elm added "See also:" with links to other security related docs
