Changes between Initial Version and Version 1 of ALL__security_access_control

Timestamp:

11/20/14 14:53:14 (10 years ago)

Author:

lttoth@…

Comment:

--

ALL__security_access_control

@@ +1 @@
+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