DLXS Authentication and Authorization System

1. Change to the directory where SQL scripts are supplied with the command (e.g.) cd /usr/local/dlps_auth/sql .
2. Carefully edit the file create_tablespace.sql , substituting the correct local customizations for Oracle data file locations as needed.
3. Carefully edit the file create_tables.sql , substituting the correct system administrator email address for sysadmin@your.domain on line 133.
   
4. Start the SQL monitor with the command sqlplus system (you will be prompted for the Oracle system password).
5. Create the schema and tablespace with the command @create_tablespace .
6. Set a new password for the dlps_auth user, exit from the SQL monitor, and restart the SQL monitor with the command sqlplus dlps_auth (you will be prompted for the new dlps_auth password).
7. Create all required tables with the command @create_tables .
8. Create the unique identifier and timestamp triggers with the command @create_triggers.
9. Define the primary keys with the command @key .
10. Create the auxiliary indexes with the command @index .
11. Define the stored procedures with the command @dlps_auth .

1. Starting on line 345, the function change_passwd contains user interface logic that lets a user select one of two Kerberos realms, and is specific to the UM environment. This section will probably need modification based on your local authentication environment.
2. Starting on line 686, the confirmation email message that is sent when a user successfully changes his/her password will need modification as is appropriate to your environment.
3. On line 1437, the domain name associated with the cookie that is used for persistent authentication should be changed to your local domain.

1. Carefully edit the file Makefile, substituting the installation paths of Kerberos, OpenSSL, and Oracle as appropriate.
2. Compile the module with the command make .
3. Install the module into your Apache installation with the command make install.

1. Carefully edit the configuration file (e.g.) /usr/local/dlps_auth/etc/dlps_auth.conf , substituting the appropriate local values, as indicated below:
1. Set DLPSAuthOracleHome to your Oracle installation home directory.
2. Set DLPSAuthOracleTNSName to the global TNS name of your Oracle server.
3. Set DLPSAuthOraclePassword to the password you assigned for the dlps_auth user in Step 2.6.
4. Set DLPSAuthEncryptionKey to 16 random characters.
5. Set DLPSAuthEnterPasswordServer to the server name you'll use to host the login page.
6. Set DLPSAuthCookieLifetime to the number of seconds you'd like authentication to persist, or 0 if you'd like authentication to expire when the user's browser is closed.
7. Set DLPSAuthChangePasswordServer to the server name you'll use to host the login page.
8. Set DLPSAuthPasswordResultsServer to the server name you'll use to host the login page.
9. Set DLPSAuthDefDestOnAuthenSuccess to a URL that the system should redirect users to after successful authentication if, for some reason, it is unable to determine the referring page.
10. Set DLPSAuthDelayOnAuthenSuccess to the number of seconds to display the page that informs the user that he/she authenticated successfully (before redirecting him/her back to the referring page).
11. Set DLPSAuthDocumentRoot to the directory containing the HTML templates, e.g. /usr/local/dlps_auth/html/templates .
    
12. Set DLPSAuthHelpContact to the email address that should receive replies to password change confirmation emails from users.
13. Set DLPSAuthSysAdminContact to the email address that should receive bounced delivery attempts to password confirmation emails
2. Reference this configuration file in your Apache configuration file with the directive (e.g.) Include /usr/local/dlps_auth/etc/dlps_auth.conf .
   
3. Restart Apache with the command apachectl restart , and check the error log to ensure that the server restarted successfully. If it didn't, you can easily remove the system from your configuration by placing a # character in front of the Include directive above and restarting Apache.

controls!

Adding access controls

In the database, an access control is made up of three parts: 1) a collection record, which is essentially one or more server names and directory paths; 2) a user or institution record; and 3) an access record indicating the user or institution and the collection. In this way, collections, users, and institutions can be defined, and access permissions can be given in any combination.

The following sequence of example SQL commands will demonstrate the routine tasks associated with maintaining access controls in the database.

Example: Creating a collection record

Example: Associating a server and directory with a collection

        insert into aa_inst (uniqueIdentifier,

        organizationName, manager,

        lastModifiedTime, lastModifiedBy,

        dlpsDeleted)

        values (1000,

        'University of Michigan', 0,

                 collection entry

                 record

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

        insert into aa_network (dlpsCIDRAddress,

        dlpsAddressStart, dlpsAddressEnd,

        dlpsAccessSwitch, inst,

        lastModifiedTime, lastModifiedBy,

        dlpsDeleted)

        values ('141.211.0.0/15',

        2379415552,2379546623,

        'allow', 1000,

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

                 record

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

        insert into aa_may_access (inst, coll,

        lastModifiedTime, lastModifiedBy,

        dlpsDeleted)

        values (1000, 'jbt',

        SYSDATE, 'root', 'f');

                 record

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

        insert inst aa_user (userid,

        givenName, initials, surname,

        rfc822Mailbox,

        dlpsKey, userPassword,

        lastModifiedTime, lastModifiedBy,

        dlpsDeleted)

        values ('cufarley',

        'Charles', 'U.', 'Farley',

        'cufarley@your.domain',

        '123-45-6789', '!none',

        SYSDATE, 'root', 'f');

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

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

                 record

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

        insert into aa_is_member_of_inst (userid, inst,

        lastModifiedTime, lastModifiedBy,

        dlpsDeleted)

        values ('cufarley', 1000,

        SYSDATE, 'root', 'f');

                 record

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

        delete from aa_is_member_of_inst

        where userid = 'cufarley' and inst = 1000;

        insert into aa_may_access (userid, coll,

        lastModifiedTime, lastModifiedBy,

        dlpsDeleted)

        values ('cufarley', 'jbt',

        insert into aa_coll (uniqueIdentifier,

        commonName,

        description,

        dlpsClass, dlpsSource,

        dlpsAuthenMethod, dlpsAuthzType,

        dlpsPartlyPublic,

        manager,

        lastModifiedTime, lastModifiedBy,

        dlpsDeleted)

        values ('jbt-text',

        'Journal of Bobbles and Trinkets',

        'An online resource focusing on the

        study of buttons, plastic toys,

        do-nothing machines, and the like',

        'text', 'local',

        'any', 'd',

        'f',

        0,

           a collection record. above:

                 classes)

                 or 'd' (delegated)

        insert into aa_may_access (inst, coll,

        lastModifiedTime, lastModifiedBy,

        dlpsDeleted)

        values (1000, 'jbt-text',

        SYSDATE, 'root', 'f');</pre> 

     </td>

                 record

        

     </td>
  </tr>