DLXS Authentication and Authorization System

insert into aa_coll_obj (dlpsServer,

dlpsPath,

coll,

lastModifiedTime, lastModifiedBy,

dlpsDeleted)

values ('www.your.domain',

'/usr/local/apache/htdocs/jbt%',

'jbt',

SYSDATE, 'root', 'f');

At this point, any attempt to access this resource, which is non-public and yet has no access permissions, should result in a prompt for authentication.

Example: Creating an institution record

<br>
         </BR>
         insert into aa_inst (uniqueIdentifier,<br>
         </BR>
         organizationName, manager,<br>
         </BR>
         lastModifiedTime, lastModifiedBy,<br>

         </BR>
         dlpsDeleted)<br>
         </BR>
         values (1000,<br>
         </BR>
         'University of Michigan', 0,<br>
         </BR>

         SYSDATE, 'root', 'f');

        </BR>

                 </BR>

                 </BR>

                 </BR>

                 </BR>

                 collection entry

                 </BR>

                 </BR>

                 </BR>

                 </BR>

                 record

                 </BR>

                 </BR>

                 either 't' (true) or 'f' (false)

                 </BR>

Example: Associating an IP address range with an institution

<br>
         </BR>
         insert into aa_network (dlpsCIDRAddress,<br>
         </BR>

         dlpsAddressStart, dlpsAddressEnd,<br>
         </BR>
         dlpsAccessSwitch, inst,<br>
         </BR>
         lastModifiedTime, lastModifiedBy,<br>
         </BR>
         dlpsDeleted)<br>

         </BR>
         values ('141.211.0.0/15',<br>
         </BR>
         2379415552,2379546623,<br>
         </BR>
         'allow', 1000,<br>
         </BR>

         SYSDATE, 'root', 'f');

        </BR>

dlpsCIDRAddress

                 </BR>

dlpsAddressStart

                 </BR>

dlpsAddressEnd

                 </BR>

dlpsAccessSwitch

                 is to be allowed or denied: either 'allow' or 'deny'

                 </BR>

inst

                 </BR>

lastModifiedTime

                 </BR>

lastModifiedBy

                 record

                 </BR>

dlpsDeleted

                 either 't' (true) or 'f' (false)

                 </BR>

The system allows multiple IP address ranges to be associated with each institution.

Example: Permitting an institution to a collection

<br>
         </BR>
         insert into aa_may_access (inst, coll,<br>

         </BR>
         lastModifiedTime, lastModifiedBy,<br>
         </BR>
         dlpsDeleted)<br>
         </BR>
         values (1000, 'jbt',<br>
         </BR>

         SYSDATE, 'root', 'f');<br>
         </BR>
         

        </BR>

inst

                 </BR>

coll

                 </BR>

lastModifiedTime

                 </BR>

lastModifiedBy

                 record

                 </BR>

dlpsDeleted

                 either 't' (true) or 'f' (false)

                 </BR>

At this point, the resource will be accessible from the UM campus, but any attempt to access it from elsewhere should result in a prompt for authentication. However, as no users currently exist, it will not be possible to authenticate.

Example: Creating a user

<br>
         </BR>
         insert inst aa_user (userid,<br>
         </BR>
         givenName, initials, surname,<br>

         </BR>
         rfc822Mailbox,<br>
         </BR>
         dlpsKey, userPassword,<br>
         </BR>
         lastModifiedTime, lastModifiedBy,<br>
         </BR>

         dlpsDeleted)<br>
         </BR>
         values ('cufarley',<br>
         </BR>
         'Charles', 'U.', 'Farley',<br>
         </BR>
         'cufarley@your.domain',<br>

         </BR>
         '123-45-6789', '!none',<br>
         </BR>
         SYSDATE, 'root', 'f');<br>
         </BR>
         

        </BR>

userid

                 </BR>

givenName

                 </BR>

initials

                 </BR>

surname

                 </BR>

rfc822Mailbox

                 </BR>

dlpsKey

                 establish or change their password using the self-serve user
                 interface; this should be known only to the user

                 </BR>

userPassword

                 realm; this should be initially set to '!none', and will be
                 set by the user

                 </BR>

lastModifiedTime

                 </BR>

lastModifiedBy

                 record

                 </BR>

dlpsDeleted

                 either 't' (true) or 'f' (false)

                 </BR>

Example: Associating a user with an institution

<br>

         </BR>
         insert into aa_is_member_of_inst (userid, inst,<br>
         </BR>
         lastModifiedTime, lastModifiedBy,<br>
         </BR>
         dlpsDeleted)<br>
         </BR>

         values ('cufarley', 1000,<br>
         </BR>
         SYSDATE, 'root', 'f');<br>
         </BR>
         

userid

                 </BR>

inst

                 </BR>

lastModifiedTime

                 </BR>

lastModifiedBy

                 record

                 </BR>

dlpsDeleted

                 either 't' (true) or 'f' (false)

                 </BR>

At this point, after being prompted for authentication, the user may authenticate and will be given access to the resource.

Example: Permitting a user to a collection

Access to collections may be given to individual users directly instead of via association with an institution. The following commands would modify the database to remove the association of the user with the institution, and explicitly permit the user to the collection. (Compare with Permitting an institution to a collection, above.)

<br>
         </BR>
         delete from aa_is_member_of_inst<br>

         </BR>
         where userid = 'cufarley' and inst = 1000;<br>
         </BR>
         <br>
         </BR>
         insert into aa_may_access (userid, coll,<br>
         </BR>
         lastModifiedTime, lastModifiedBy,<br>

         </BR>
         dlpsDeleted)<br>
         </BR>
         values ('cufarley', 'jbt',<br>
         </BR>
         SYSDATE, 'root', 'f');

Example: Creating a DLXS text class collection record

Collections served by DLXS class middleware use a special mode of the system called "delegated authorization", which will be explained in more detail in the next example. First, though, to trigger this mode, DLXS class collections must specify both their class (e.g. text or image) and the appropriate authorization type flag, as shown below:

<br>
         </BR>
         insert into aa_coll (uniqueIdentifier,<br>

         </BR>
         commonName,<br>
         </BR>
         description,<br>
         </BR>
         dlpsClass, dlpsSource,<br>
         </BR>

         dlpsAuthenMethod, dlpsAuthzType,<br>
         </BR>
         dlpsPartlyPublic,<br>
         </BR>
         manager,<br>
         </BR>
         lastModifiedTime, lastModifiedBy,<br>

         </BR>
         dlpsDeleted)<br>
         </BR>
         values ('jbt-text',<br>
         </BR>
         'Journal of Bobbles and Trinkets',<br>
         </BR>

         'An online resource focusing on the<br>
         </BR>
         study of buttons, plastic toys,<br>
         </BR>
         do-nothing machines, and the like',<br>
         </BR>
         'text', 'local',<br>

         </BR>
         'any', 'd',<br>
         </BR>
         'f',<br>
         </BR>
         0,<br>
         </BR>

         SYSDATE, 'root', 'f');

           a collection record. above:

        </BR>

                 </BR>

                 classes)

                 </BR>

                 </BR>

                 or 'd' (delegated)

                 </BR>

        

        </BR>

Example: Permitting an institution to a DLXS text class collection

When a permission is given to a collection that is set for delegated authorization, as above, the system behaves in a completely different way. Instead of acting as a gatekeeper, the system instead collects all pertinent authorization information and passes that information via environment variables to the DLXS middleware. The DLXS middleware will then use that information to decide which collections to present to the user.

This mode is necessary because DLXS middleware supports searching across multiple collections. Because any given user may have different access permissions based on institutional associations or explicit permissions, it is impossible to simply grant or deny access on a global basis. Instead, the DLXS middleware must be supplied with a customized list of authorized collections on a per-transaction basis in order to present the user with all of the material they are permitted to access, and none of the material for which they are not. The authorization type is referred to as "delegated" because the system is "delegating" the authorization decision to the DLXS middleware.

For a description of the information that is passed from the system to the DLXS middleware and how it is used, see <a href="../auth/index.html">DLXS Authentication and Authorization</a>.

As you can see below, the command required to add the permission is the same regardless of the authorization type:

<br>
         </BR>
         insert into aa_may_access (inst, coll,<br>

         </BR>
         lastModifiedTime, lastModifiedBy,<br>
         </BR>
         dlpsDeleted)<br>
         </BR>
         values (1000, 'jbt-text',<br>
         </BR>

         SYSDATE, 'root', 'f');

        </BR>

        </BR>

inst

                 </BR>

coll

                 </BR>

lastModifiedTime

                 </BR>

lastModifiedBy

                 record

                 </BR>

dlpsDeleted

        

        </BR>

Appendix: Features of the UM Digital Library Services Installation

Our local installation of this system includes the following:

• Oracle configuration. Two Oracle 9i servers are installed in two different, and distant, parts of campus. These servers use replication features of Oracle to stay in near-real-time synchronization; if a change is made on one server, that change will be replicated to the other server in less than one minute. All Oracle client software has been configured with connect-time and session failover capabilities so that the Oracle server which is physically closest is preferred under normal circumstances, but the other will be chosen in the event of a failure. One server is Sun hardware running Solaris, and the other is Intel hardware running Linux.
• Apache web server configuration. Apache, equipped with mod_ssl and the DLXS authentication and authorization system, is running alongside Oracle on each server. Each Apache installation is configured with a copy of a server certificate for the name "login.umdl.umich.edu" and has identical appearance in all respects.
• Load balancing and failover. A DNS-based system has been put in place to dynamically direct users' browsers to the Apache server that is physically closest under normal circumstances, to the least loaded server under heavy usage conditions, or to the only available server in the event of a failure. A user accessing the server "login.umdl.umich.edu" may transparently hit either server.
  
• Locally-hosted text and image resources. Servers that are dedicated to serving text and image content are equipped with the DLXS authentication and authorization system if they host any non-public content. The database is maintained with records which restrict access to these materials as needed. At the time of this writing, there are approximately 500 active institutions records in the database for institutions with subscriptions to resources hosted by DLS.
• Library web server. The library's main web server also has the system installed, and restricted access to materials such as course reserves and staff-only areas of the website is provided through the system via IP address range or password authentication, as appropriate.
• Library catalog. The Web-accessible interface to the library's catalog has been enhanced to honor the authentication cookie used by the system, and uses that to enable saved record sets, patron self-service functions, and other functions requiring authentication.
• Library proxy server. The library's proxy server, EZProxy, was enhanced with a small custom script to honor the authentication cookie used by the system to initialize a proxy session. UM affiliates who have authenticated for other reasons are automatically granted a proxy session.