CUWebAuth is Cornell's single sign on system. I wrote a module to use this to authenticate Drupal users. The module allows users to log in to their Drupal site using CUWebAuth credentials.  It creates Drupal accounts for CUWebAuth authorized users so they don't have to remember a password for each site, and so users who become unauthorized will no longer be able to edit the site. By default this requires users to be in the 'library' CUWebAuth permit group, but the administrator can change that to another group or eliminate the requirement.

What the user sees is an "Authenticate' button under the usual login dialog. Clicking brings the user to the CUWebAuth page. The user logs in, and is returned to Drupal. If the returned user does not have an account on this site, they get a second 'New Account' button - click that and they get a Drupal account. If the user has an account already, they just land on their account page in a logged in state.

  • The module is called culauth and is located in sites/all/modules/custom when installed.
  • How to Use culauth
    • Install culauth and autologout modules
    • configure administrative settings
      • admin/settings/autologout - check off Enable Module
      • Under the list of blocks at /admin/build/block find the block 'CUWebAuth Login'
      • configure the block
        • If you want to require a certain CUWebAuth permit of your users add it under 'Required CUWebAuth permit (eg. library):'
        • under 'Page specific visibility settings' select 'Show on only the listed pages.' and add 'user' to the list of pages.
    • move the block into a visible region, like 'content bottom'
    • The /admin/user/settings should be set to 'Only site administrators can create new user accounts.'. (We don't want people with netids creating regular Drupal accounts with their netid as a user name. We want to verify that their netid is still valid whenever they log in.)
  • The module is based on Adam Smith's work in the cul_common module. It uses cul_common's api for accessing LDAP data.
  • culauth contains
    • a form for the login dialog
    • a block to display the form in,
    • various hooks to catch the login
    • the login code
    • administrative form code to maintain a permit group setting
  • To trigger the CUWebAuth authentication, culauth jumps to a .php file in a protected directory using drupal_goto. Since the directory is protected, CUWebAuth takes over and presents the Cornell login dialog before the user gets to the .php file. The directory is protected by an .htaccess file containing this:

    AuthName CORNELL
    AuthType All
    require valid-user

  • The actual .php file adds 2 cookies that tells culauth what the user's netid is.
    1. The user's netID
    2. A hash that confirms the other cookie was added by culauth
  • Given the authorized netid, the module creates a Drupal user account with that netid. No roles are assigned to the user.
  • Once the Drupal account is created, the authorized user can log in without a password - just click the log in button.
  • The CUWebAuth cookie expires at the end of the browser session. To log in after browser restart the user should have to go through CUWebAuth again. See these issues regarding ending sessions on various browsers and platforms.
  • With the default setup, the Drupal login session does not expire on browser restart. You can get in a situation where you are logged in to Drupal but there is no CUWebAuth cookie. This is not good. I think we should change our settings.php files to arrange for terminating Drupal login when the browser closes with:

    ini_set('session.cookie_lifetime', 0);

  • culauth requires a module called Automated Logout that kills the Drupal session after an hour of inactivity. (The administrator of the site must remember to turn on this feature in the Automated Logout settings.)
  • This system works with the regular Drupal logins also. User #1 uses the regular login. Users outside of Cornell can be given accounts by the admin if necessary.
  • Here are some details about the culauth module.
  • No labels