# Summary

This module provide single sign-on capability for your Drupal site by implementing the CAS protocol. CAS has quickly become the most popular single sign-on solution for universities. In its most simple use (CAS can also proxy single sign-on), CAS authenticates users and sends the user to the requested application (your Drupal site) with a special ticket. The application (your Drupal site) is then responsible for authenticating the ticket (behind the scenes, with a tool like cURL) and automatically logging the user in if the ticket is valid.

There is a 8.x-1.x-dev Development release of the module for D8.

# Project URL

https://www.drupal.org/project/cas

# Where is the code?

https://www.drupal.org/project/cas

# Estimated completion date

Unknown

# Dependencies

Unknown

# Who's doing the port?

# What help do they need?

Unknown

# D8 roadmap

#2723569: CAS Drupal 8 Release Plan

# Background and reference information

Unknown

Comments

legaudinier created an issue. See original summary.

Shawn DeArmond’s picture

Issue summary: View changes
bkosborne’s picture

Issue summary: View changes
bkosborne’s picture

We have a meta task issue in the CAS queue for this now: #2723569: CAS Drupal 8 Release Plan

xeM8VfDh’s picture

I am using this module on a D8 development site. When I migrated my old Drupal 6 site's data over, the user handling just seemed to work with the D8 CAS module, which is great! However, when I try to add a new user on the D8 site, Drupal's required password field is problematic. The migrated users have blank password fields, without the required (*) notation. But when I try to create a new user, the password field is marked required, and I can't submit it blank.

On my D6 site, there is an option at the top of /admin/user/user/create to "Add CAS user", which takes me to /admin/user/user/cas/create, where there is no password requirement. I do not see any method of doing this with the D8 module.

Is it my responsibility to simple give each new user on the D8 site a strong random password, and when they authenticate through CAS, that password will be used or bypassed to authenticate the CAS user into the corresponding Drupal user record? If not, is there something I am missing, or something you suggest I try?

Thanks for all of the great work!

bkosborne’s picture

There's a couple issues I picked out from your comment:

1) There's no way to add a CAS user simply by providing a CAS username for that user like there is in D6 and D7. Instead on the new user registration form, we have a CAS username field. The problem here is that the password field is required on this form even when registering the user as a CAS user. For now, you should indeed just generate a strong random password for this user. It will never be used, but it must be submitted.

2) Looks like somewhere down the line we stopped assigning randomly generated passwords for automatic CAS user registrations, so they just come out blank. Even though these users are not supposed to authenticate via Drupal login directly, we still should set a strong random password for these users. I've created an issue to resolve that: #2823615: Set a randomly generated password when auto-registering new accounts.

xeM8VfDh’s picture

Thanks @bkosborne, thats very helpful information. I am still running the 8.x-1.x-dev branch from a few months ago. When I initially set it up, there was no CAS username field, so I added a similar field to the profile a wrote a custom module to use a number of hooks to display the CAS username value instead of the drupal username value throughout the application. Is the new CAS username field that you've added set up to override the drupal username throughout the application? If so, this is great!

Thanks again,

bkosborne’s picture

No it's not, it's used exclusively to map the Drupal user account with the CAS username. If users are automatically registered to your site via CAS on first login, the Drupal username will be default be the same as the CAS username.

Is there a reason your CAS usernames are different from the Drupal usernames?

xeM8VfDh’s picture

Our CAS usernames are different from our Drupal usernames because, in our system, the former is an (otherwise) meaningless ID number, and we want a meaningful name to be used/displayed instead of the number (which might confuse people). I think we can just use the ID number in the new "CAS username" field and the real name/string in the standard Drupal username field, which should allow me to get rid of the custom module we wrote.

Is there, by chance, a policy for this project to only allow non-breaking commits into the dev branch? In other words, can we assume its safe (non-breaking) to update to the latest dev branch commit, or do you advise holding off until an the alpha/beta/rc is published?

Also, is the CAS username field now injected into the User form, as per the current dev branch commit?

Thanks again for the very quick and helpful responses!

bkosborne’s picture

We're working on finalizing the API in #2820164: Evaluate all the ways we want contrib modules to interact with CAS and ensure we support them. Once that's done there will be a way for you to create a small module that alters the automatic registration of user accounts so that the Drupal username that's created for the user is different from the CAS username. You could query LDAP or something and set the Drupal username and other user fields during auto-registration if you want.

Indeed the latest dev version injects a CAS username field to the Drupal user form.

There's no policy to introduce non-breaking changes only - that's why we're in dev release still. We plan to release a beta soon and after we do that, we will not introduce breaking changes. Note that when you DO upgrade, there's a new dependency - externalauth. It creates a database table and you'll have to create entires for all your CAS users in there.

xeM8VfDh’s picture

Thanks for the extremely helpful update @bkosborne. For reasons I won't get into, we don't use auto-registration, so hopefully we won't actually need to interact (via custom code) with the API you are working on, but its awesome that you are making this API available.

I'll probably hold off on updating until the Beta is out, but am happy to provide my testing results after that. Things are looking great so far.

I'm really glad you mentioned the new dependency/database record creation requirement. That might have thrown me for a loop!

bkosborne’s picture

Status: Needs review » Fixed

I just released the first beta. I think this issue can be closed now.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

mmjvb’s picture

Please set Status to RTBC to reflect that there is an RC, no Stable yet!

It requires a maintainer to do this!