20081103 elm              EDIR/AUTHSERV Access Control

See also:

        https://donnelly.alaska.edu/docs/LDAP/ALL__security
        https://donnelly.alaska.edu/docs/LDAP/ALL__security_account_admin

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 via the update 
back end (see note above).

#######################
DOCUMENT CHANGE HISTORY

20081031 elm	corrected typo
20081103 elm	added "See also:" with links to other security related docs

#eof