#Implementing CAS single sign on in Drupal 8.
-When we want to provide true omni-channel solutions that are tailored to the individual there can be concerns when handling multiple authentication portals and authorization stores. Users have to sign into multiple interfaces and remember credentials for those applications. These in turn are managed by an IT team with the responsibility of ensuring these systems not only function but are also secure. This task becomes exponentially more difficult and expensive as services are added to the platform. The answer for this problem is a single sign-on solution that allows a user to sign in only one time to a central authentication provider and then be automatically authenticated to other services in the ecosystem. SSO options range from custom solutions to proprietary and open source technologies. If your working in academia however, a common choice is Central Authentication Store (CAS).
+When we want to provide true omni-channel solutions that are tailored to the individual there can be concerns when handling multiple authentication portals and authorization stores. Users have to sign into multiple interfaces and remember credentials for those applications. These in turn are managed by an IT team with the responsibility of ensuring these systems not only function but are also secure. This task becomes exponentially more difficult and expensive as services are added to the platform. The answer for this problem is a single sign-on (SSO) solution that allows a user to sign in once to a central authentication provider and then be automatically authenticated to other services in the ecosystem. SSO options range from custom solutions to proprietary and open source technologies. If you're working in academia however, a common choice is Central Authentication Service (CAS).
-CAS (Central Authentication Service) is a single sign-on service that can be integrated into or replace your web application authentication. It is an open source project with roots in Yale University and exits today as a widely used protocol for single sign-on in the educational universe. CAS itself isn't involved in storing credentials. It serves as a common interface for a number of available authentication handlers such as: databases, LDAP, RADIUS, OAuth, OpenID and more.
+CAS is a SSO service that can be integrated into or replace your web application authentication. It is an open source project with roots in Yale University and exits today as a widely used protocol for SSO in the educational space. CAS itself isn't involved in storing credentials. It serves as a common interface for a number of available authentication handlers such as: databases, LDAP, RADIUS, OAuth, OpenID and more.
-The process starts when a user visits a CAS client--a CAS-iffied web application if you will. When a user wants to login to the client app (or is forced to), they are redirected by the client to the CAS login endpoint where they must authenticate. Upon successful authentication at the CAS portal the user is redirected back to the client app with whats known as a CAS Ticket Granting Ticket (CASTGT) and a Service Ticket (ST). The client then sends a second request to CAS to validate the tickets. Upon successful validation CAS sends a reply to the client with the user id and a success message. Finally with this information the client logs the user in.
+The process starts when a user visits a CAS client--a web application configured to work with CAS. When a user wants to login to the client app (or is forced to), they are redirected by the client app to the CAS login endpoint where they must authenticate. Upon successful authentication at the CAS portal the user is redirected back to the client app with what is known as a CAS Ticket Granting Ticket (CASTGT) and a Service Ticket (ST). The client app then sends a second request to CAS to validate the tickets. Upon successful validation CAS sends a reply to the client with the user id and a success message. Finally with this information the client app logs the user in. If some of the logic in the workflow looks familiar, it might be because CAS is modeled after the [Kerberos](https://en.wikipedia.org/wiki/Kerberos_(protocol)) protocol.
-If some of the logic in the workflow looks familiar, it might be because CAS is modeled after the [Kerberos](https://en.wikipedia.org/wiki/Kerberos_(protocol)) protocol.
+
+Source: https://apereo.github.io/cas/4.2.x/planning/Architecture.html
+There are several pre-packed CAS client libraries for various programming languages that can be leveraged within your client app. Packages exist for [.NET](https://wiki.jasig.org/display/CASC/.Net+Cas+Client), [Java](https://wiki.jasig.org/display/CASC/CAS+Client+for+Java+3.0), [Apache](https://wiki.jasig.org/display/CASC/mod_auth_cas), [PHP](https://wiki.jasig.org/display/CASC/phpCAS) and [more]().
-For those of us working in Drupal we are fortunate that we do not have to build the toolset to communicate with CAS by hand. Meet the [CAS module](http://drupal.org/project/cas). Out of the box the CAS module gives us everything we need to get a user authenticated to our Drupal site with CAS as the authentication provider. Today we will be talking specifically about how to get CAS going in D8, but never fear there is a D7 version of the module too.
+For those of us working in Drupal we are fortunate that we do not have to build the toolset to communicate with CAS by hand. Meet the [CAS module](http://drupal.org/project/cas). Out of the box the CAS module gives us everything we need to get a user authenticated to our Drupal site with CAS as the authentication portal. Today we will be talking specifically about how to get CAS going in D8, but never fear there is a D7 version of the module too.
Download the 8.x-1.x-dev version of the CAS module from https://drupal.org/project/cas, unless there is a tagged D8 release in which case use that instead. Install the module.
-Once the CAS module is installed, head to _/admin/config/people/cas_ to configure it. You will be presented with a configuration form that can seem overwhelming at first given the amount of options, so lets cover each of them a briefly.
+Once the CAS module is installed, head to _/admin/config/people/cas_ to configure it. This configuration form can seem overwhelming at first given the amount of options, so lets cover each of them a briefly.
- **Version:** This is the version of the CAS protocol that your site will use to communicate with the CAS endpoint. Use the one that matches your CAS server configuration.
- **URI:** This is the path on the server that represents your primary CAS endpoint. Typically "/cas".
-- **SSL Verification:** Options for dealing with SSL verification. If your CAS server is using a self-signed certificate you will need to choose the "Do not verify CAS server" option. Be warned though that this is never a good idea as it weakens your security.
+- **SSL Verification:** Options for dealing with SSL verification. If your CAS server is using a self-signed certificate you will need to choose the "Do not verify CAS server" option, but this is never a good choice as it weakens your security.
- **Gateway:** Logs a user into Drupal if they are already logged into CAS. The CAS server will not "paint" the user logon screen but seamlessly log the user in using their existing CASTGT.
- **Drupal Logout Triggers CAS Logout:** When you logout of Drupal, you log out of CAS as well. The site will send CAS your logout request and you will be logged out of Drupal at the same time.
-- **Enable single log out:** When you logout in CAS, you logout of Drupal. This is not a recommended settings since it allows your session to be stored un-hashed.
+- **Enable single log out:** When you logout in CAS, you logout of Drupal. This is not a recommended setting since it allows your session to be stored un-hashed.
- **Proxy:** Leverages the proxy features in CAS.
-- **Debugging:** Logs debugging information to Drupal watchdog. Very handy when developing but beware of the log clog it can create.
+- **Debugging:** Logs debugging information to Drupal watchdog. Very handy when developing but should be enabled on an as-needed basis in production due to the log spam it can create.
+### Step 3: Login with CAS
Lets assume for the sake of this discussion that we have configured our Drupal site as such:
- Auto register users: disabled
-### Step 3: Profit (Use CAS)
-As an anonymous user, visit your Drupal site and try to login with the above settings and you will be presented with the core Drupal login form. So why aren't we being redirected to CAS for authentication? The answer is a combination of our configuration settings combined with how the CAS module is works in D8.
-#### Forced Login and Gateway
-Our configuration has the *forced login* and *gateway* options disabled, so CAS won't be invoked by force on a user.
+As an anonymous user, visit your Drupal site and try to login with the above settings and you will be presented with the core Drupal login form. So why aren't we being redirected to CAS for authentication? To find that answer we need to understand a bit more how the CAS module works to in D8.
#### How the CAS module works
-With the CAS module enabled and configured, visiting the /user/login path one might expect to be redirected to the CAS server endpoint. However the CAS module doesn't work that way. Instead, it provides its own path to trigger a CAS authentication workflow.
+Recall that our configuration has the *forced login* and *gateway* options disabled, so CAS won't be invoked on a user by force. But by visiting the */user/login* path one might expect to be redirected to the CAS server endpoint. However the CAS module doesn't work that way. It provides its own path to trigger a CAS authentication workflow.
-Warning, Drupal 8/Smfony concepts ahead!
-Instead of modifying the /user/login route path, the CAS module provides a new route at /caslogin. The controller for this route is responsible for creating the redirect to CAS. The redirect specifies the location of the CAS server as well as the url of the client CAS should send the user to after authenticating. To accomplish this the HTTP response includes a query string parameter, **service**, appended to the location value of the header.
+Instead of modifying the /user/login route path, the CAS module provides a new route at */caslogin*. The controller for this route is responsible for creating the redirect to CAS. The redirect specifies the location of the CAS server as well as the url of the client app that CAS should send the user to after authenticating. To accomplish this the HTTP response includes a query string parameter, **service**, appended to the location value of the header.
└╼ curl -I http://example.com/caslogin
Content-Type: text/html; charset=UTF-8
-The CAS module exposes another route path at /casservice who's controller is responsible validating the tickets and logging in the user to Drupal. It is this second round of communication with the CAS server that authentication happens. With the successful authentication response from the CAS server, the module performs its conditionals based on the configuration and determines if the now-Authenticated CAS user should be logged into Drupal. The module maps the user id from CAS as the Drupal user name. So if CAS returns a user id if 'xyz123' along with the success message, that name is used as the Drupal user name logic checks. And in the case of our configuration, the Drupal user xyz123 needs to exist in order to be logged in. To have xyz123 be automatically logged in as a new user, we would need to enable the **auto register users** option in the CAS configuration form.
+The CAS module exposes another route at */casservice*. This route controller is responsible sending the CASTGT and ST tickets to CAS for validation and logging in the user to Drupal. With a successful authentication response from the CAS server, the module determines if the now-authenticated CAS user should be logged into Drupal. When doing so, the module maps the user id from CAS as the Drupal user name. So if CAS returns a user id of xyz123 along with the success message, that name is used as the Drupal user name during processing. In our case the Drupal user xyz123 would need to exist in order to be logged in. To have xyz123 be automatically logged in as a new user, we would have to enable the **auto register users** option in the CAS configuration form.
-If we wanted to force users through the CAS workflow for authentication we would enable the **forced login** CAS configuration option. Once enabled, if a user visits a page that matches the conditions of the forced login or gateway options, the CAS module will take over and perform the redirect if necessary. To make the forced login and gateway features work, the CAS module adds an event listener to early kernel requests. In the event handler, CAS triggers the gateway and forced login condition checks and returns a redirect response if the user needs to be sent to CAS for authentication:
+To make the forced login and gateway features work, the CAS module adds an event listener to every page request. In the event handler, CAS triggers the gateway and forced login condition checks and returns a redirect response if the user needs to be sent to CAS for authentication:
$event->setResponse(new CasRedirectResponse($cas_login_url));
-Now that we have a better understanding how the CAS module works we can explain why we were not able to trigger CAS authentication by visiting /user/login, but that we can do that by instead going to /caslogin. And that by configuring the CAS module for forced login, the user never sees the core Drupal login prompt.
+The CAS module adds its own events that other modules can subscribe to that hook into the processing workflow.
+- CasPreAuthEvent: allows modules to change data received from CAS before attempting to load a Drupal user.
+- CasUserLoadEvent: listeners can prevent user from logging in or modify user attributes before they are saved to the Drupal account.
+CAS isn't overly complicated but there are a lot of touch points to be concerned with. There is some upfront configuration necessary but with the knowledge you now have you should be able to sail through that easily.
