The following settings should be adequate for most Georgia Tech developers using Drupal version 10.
The CAS configuration page can be found on the black administration toolbar under
Configuration -> People -> CAS
Alternatively, you can access the configuration page by adding "
/admin/config/people/cas" to the end of your site's front page URL.
- Version — 3.0 or higher
- HTTP Protocol — HTTPS (secure)
- Hostname — sso.gatech.edu
- Port — 443
- URI — /cas
- SSL Verification — Verify using your web server's default certificate authority (CA) chain.
All other sections are optional, but you will want to either:
- Enable Login link enabled under the GENERAL SETTINGS section (to show a CAS login link on the regular Drupal login form/page). This could be combined with the GATEWAY feature to speed up login for users already logged into their GT Account.
- Post a link to
/casloginto your front page
- Configure the FORCED LOGIN section, should you want to have visiting a path like
/userautomatically to log the user into CAS
NOTE: The Drupal 8 CAS module originally used a different login path (
/caslogin) from what CAS used in Drupal 6 and 7, which was
/cas . However, the module now supports both URL paths, though it considers
/cas to be a legacy path.
An explanation on GATEWAY: this feature will check to see if the user is already logged into his/her GT Account and if so log him/her into the website. If the user is not already logged in, then the user will simply access the site as a guest (anonymous) user. For this reason, you must also enable the login link setting or post a login link to your front page to allow users to log into the site when they are not already logged into their GT Account. (All GATEWAY does is to save users the trouble of selecting a login link when they've already logged into their GT Account.)
Important: If you turn on both GATEWAY logins and Auto register users, then every Georgia Tech user who visits your site and is already logged into their GT Account will have a Drupal account created for them on your site. This can result in your site ending up with thousands of user accounts, which can be a headache when it comes to managing the accounts of users who actually have special editing privileges on your site. In general, you really don't want to configure a site this way unless you specifically want to allow all Georgia Tech community members to be able to create content and/or post comments to existing content. An example of this kind of usage is this Georgia Tech Drupal community site.
The FORCED LOGIN feature will require every visitor to have a Drupal account on your site and will log the visitor into their account when first accessing the site in a browser session. Visitors who do not have a Drupal account will be denied access to the site. You probably do not want to enable this for the whole site (unless the site is meant to be a private intranet), but it can be useful to enable FORCED LOGIN for subsections of a site (e.g. "
/admin/*" to automatically force login when trying to access any administrative page.)