Editor's Note: If you are using Drupal Express (Drupal 10 or Drupal 7), then CAS is already installed as part of your Drupal Express installation.  You may want to look at the sections here about configuring CAS, should you want to customize your configuration, but you do not need to go through any of the installation processes.

There are two components needed to add CAS support to a Drupal website: the phpCAS Library, and two supporting Drupal modules.

phpCAS Library

This library is only needed for Drupal 7.  If you are installing the CAS module for Drupal 10, you can skip this section.

1. Download and install the current, stable version of the phpCAS Library.  As of 2019, the current version was phpCAS 1.3.8 – if you are using and older version, you should consider upgrading as soon as possible to get the latest security patches.
2. Install it under the sites/all/libraries/ directory of your Drupal site.  Rename the top level directory to CAS so that you have the CAS.php file inside of sites/all/libraries/CAS/

Drupal Modules

You will need to configure CAS to talk to the Georgia Tech CAS service.

1. Log into the special original user account (user #1) that you setup when creating your Drupal site.  This is the main administrative account that has full power over everything in your site.  If this account is the same as someone's GT Account Username, you should rename the account to something else (good names are "root" or "admin", which make it easy to identify the account later on.
2. For Drupal 10, download and install the External Authentication and CAS modules into your Drupal site's sites/all/modules/ directory, or if your site supports it, install them via the Install Module option in the Modules section of your site's administrative controls.
3. For Drupal 7, download and install the Libraries and CAS modules into your Drupal site's sites/all/modules/ directory, or if your site supports it, install them via the Install Module option in the Modules section of your site's administrative controls.
4. Go to the Modules page of your site's administrative controls and enable (turn on) both modules.  Once you have enabled these modules DO NOT LOG OUT OF THE SITE until you have finished the remaining steps.  Otherwise, you will find yourself locked out of your site!
5. For Drupal 7 only, go to the Permissions page of your site's administrative controls (found under the People section), and make sure that the following permissions are enabled for the highest level user role in your site (commonly "administrator", or for sites using the GT Profile, "super administrator") (Don't forget to save your changes!) :
   • CAS -> Administer CAS
   • User -> Administer Permissions
   • User -> Administer Users
6. Go to the CAS settings page of your site's administrative controls (found under the Configuration -> People section) and configure your CAS settings (see Drupal version specific links below for more details).
7. Add a new user to the site with the username and "CAS username" both being the same as your GT Account Username.  Set the other fields as needed (enter a random value for the password field) and give the account the highest access level available (usually 'administrator').  Don't forget to save the new account.
8. In a different web browser from the one in which you are currently using (or via your browser's private browsing feature), browse to your Drupal site and verify that you can login with your personal GT Account Username and password.  You should not see the normal Drupal login prompt - if you are prompted at all, you should be taken to the Georgia Tech Login service and then brought back to the Drupal site after you've successfully logged in to your GT Account.
9. Repeat step #7 above for each user who should have access to the site, setting the access level as appropriate for the individual user.

CAS Configuration Guides

Drupal and CAS utilize different logout functions. Sending the user to /logout will log the user out of your site only and just return the user to the front/home page.

Sending the user to /caslogout will log the user out of your site and redirect the user to the logout page for CAS.

One way to send users to the CAS logout page without hunting down and changing every script that calls logout is to set up /logout as an alias for /caslogout.

Setting up the Alias

• While logged in as an administrator, go to Configuration -> Search and metadata -> URL aliases -> Add alias (/admin/config/search/path/add)
• Enter caslogout in the Existing system path field
• Enter logout in the Path alias field
• Select the Save button.

If you are using the CAS module for user authentication, you can require users to be logged in to their GT accounts before they can access specific pages on your Drupal site.

Enabling Restrictive Access (Drupal 7)

1. Visit the CAS configuration page on your Drupal 7 site, at Configuration -> People -> CAS settings
2. Under REDIRECTION, locate Require CAS login for and check the setting for specific pages.
3. In the textbox under Specific pages, type in one page path per line (with no starting slashes)
4. Select Save configuration at the bottom of the page once completed.

Enabling Restrictive Access (Drupal 10)

1. Visit the CAS configuration page on your Drupal 10 site, at Configuration -> People -> CAS
2. Under FORCED LOGIN, locate Pages and type in one page path per line (include starting slashes)
3. You may need to select the Enabled checkbox - untested and unclear as to whether Enabled has to be on when only forcing logins on specific pages.
4. Select Save configuration at the bottom of the page once completed.

Commonly Protected Paths

Commonly protected paths include:

• 'contact' for the site-wide contact form
• 'user' for the site-wide login page
• 'forms/*' for every form you create under this fake directory

Courtesy of Doug Curtis in OIT:

People are receiving a 500 error when using the "GT Logout" link on a Drupal page.  It looks like the problem is that the Drupal CAS module is appending the "service=" query string to the end of the CAS logout URL.  The GT CAS server will accept "url=" query string but it doesn't accept the "service=" query string.  Previously, the CAS service would quietly ignore appended query strings it didn't recognize but that isn't currently the case.

The way to fix this is to leave the "Logout destination" field blank in the phpCAS module's settings.  The "Logout destination" is supposed to be used to specify a URL to redirect the user to after the user has been logged out.  It is NOT supposed to be the URL for logging out of CAS.  By leaving the field blank, the application will be logged out of your Drupal site, but the user will still be authenticated in CAS.

While the phpCAS library is pretty stable, its maintainers do still release updates periodically, and every now and then one of those updates is to fix a security issue. Below are step-by-step instructions for how to update your phpCAS library to the most current, secure version.

For this example, we will update from version 1.3.2 to version 1.3.3, but the same steps should apply to updating between any versions of the phpCAS library (which allows logins with GTaccounts to our drupal sites).

1. Download the latest version of phpCAS from the phpCAS website.
2. If you don't want to use ssh/command line, "extract" the files from this compressed archive on your computer (Windows users can use the free 7-zip program to do so), which will create a folder called CAS-1.3.3, that has another CAS-1.3.3 directory and a package.xml file inside it.
3. Change the name the second CAS-1.3.3 folder (that is inside the other) to CAS.
4. Zip up that re-named "CAS" folder...usually by right-clicking and choosing either Compress "CAS" (on a Mac OS X computer) or Send to -> Compressed (zipped) folder (on a Windows computer).
5. Now that you have a friendly zipped file, named "CAS.zip", find where the CAS library lives on your server. The best practices location on a Drupal site is under the "sites/all/libraries" folder (which often requires you to add the Libraries module to your Drupal site, first).
6. Then, turn on your TEST site's maintenance mode (because, of course, you are not trying this out on your live site). For Drupal 7, you can enable this at: admin/config/development/maintenance
7. Delete the current version of phpCAS that lives at sites/all/libraries, so that there is no "CAS" folder anymore.
8. Upload your new CAS.zip file to your Test site's libraries folder, so that it looks like this: sites/all/libraries/CAS.zip.
9. Check the box next to CAS.zip in your web hosting panel and then, from the menu of options at the top of your file list, choose More -> Extract Files and then select Okay.
10. Once you see your new "CAS" folder, you can then delete the "CAS.zip" file from this directory and your library has been updated.
11. Remove your Test site from maintenance mode and make sure it works correctly.
12. If all goes well, follow the same process on your Live site.

CAS is capable of delivering some GTED attributes for the person logging in to Drupal, as part of the login process.  This means you don't have to configure and maintain an LDAP module nor manage an LDAP service account (read: no need to keep up with an expiring service account password).

While Georgia Tech's CAS service will provide authentication for any site within the ".gatech.edu" domain, by default it won't release any attributes.  You'll have to request what attributes your application needs by filling out the OIT IAM Data Steward Request Form (this is the same web form that you use to request a GTED LDAP service account.)  Make sure you specify CAS authentication and whatever data you need under Data Request.

Once that has been approved and CAS has been set up, configure Drupal to talk to CAS just as it's documented here on previous pages, except for the CAS Server Version, which needs to be set to SAML Version 1.1.  If the user's email address is one of the attributes you're requesting from CAS, then you'll want to leave the email address field under User Accounts blank.

Now, under the Attributes tab, select the CAS Attribute Tokens button (not the "LDAP Attribute Tokens" if you have that).  It should show you a list of attributes Drupal is getting from CAS.  You may have to log out and log back in.  If you don't see the list, you may have to work with whoever handled your data steward request, sometimes these things take a bit of tweaking to get right.

Still on the Attributes tab, select the Settings button.  You'll want Drupal to Fetch CAS Attributes "everytime a CAS user logs in" because, well, people's data changes all the time.  You'll probably also want to always Overwrite existing values from attributes, to make sure Drupal doesn't store any old data.  Under CAS ATTRIBUTE MAPPINGS, specify "[cas:name]" for the Username field and "[cas:attribute:email_primary]" (assuming you requested that) as the E-mail address field.

There is a public-facing LDAP server from which you can pull general directory information from without authentication.  This server is only accessible from servers and workstations located on one of the Georgia Tech campus subnets.

Connection Settings

Use the default settings, unless otherwise stated beow:

• LDAP Server Type - Open LDAP
• LDAP Server - ldap://whitepages.gatech.edu
• LDAP Port - 389
• Binding Method - Anonymous Bind
• Base DNs for LDAP users, groups, and other entires this server configuration - dc=whitepages,dc=gatech,dc=edu
• AuthName attribute - uid
• Email attribute - mail

Testing Queries

To test queries, see the OIT article on LDAP.

Specific Clients

• Mac Mail: LDAP Server: whitepages.gatech.edu (adding "ldap://" into the field causes the lookup to fail for me. --Sterling)