MENU

CAS Apache module

History

Before SFU adopted CAS as its authentication method for the web, we already had an Apache authentication/authorization module that allowed limited access control based on maillist membership. With the arrival of CAS, we modified a version of mod_cas (later mod_auth_cas) that would allow Apache to use the SFU version of CAS version 2 (later CAS version 3) to grant access based on SFU maillists.

With the arrival of CAS 5, the changes made to CAS by SFU are no longer needed, and the latest unchanged version of mod_auth_cas can be used. This version supports Apache 2.4 (which the older SFU modified version of mod_auth_cas does not). Because the 2.2 version of Apache is no longer being maintained by The Apache Software Foundation, you may want to upgrade your Apache, but that will also require that you upgrade to the latest version of mod_auth_cas.

Can we continue to use the older version of mod_auth_cas?

The short answer is yes. However, that version of mod_auth_cas does not support Apache 2.4, so you are stuck with the older non-maintained version of Apache. There are a few other things to keep in mind if you want to continue using the old SFU version of mod_auth_cas.

For example, in order to do the authorization, the SFU modified mod_auth_cas uses an SFU added feature of CAS, and adds an "allow=" string to the login and serviceValidate CAS entry points. We have added support for this to CAS 5 to continue to support the old mod_auth_cas, but this may not be supported in future upgrades to CAS.

Another thing to keep in mind is that mod_auth_cas needs attributes from CAS to do the authorization work. The older versions of CAS didn't return attributes, so SFU modified CAS so that you could get the needed attributes from serviceValidate. In CAS 5, attributes are returned using p3/serviceValidate, but not with serviceValidate. We have added a setting in CAS 5 to allow some attributes to be returned by serviceValidate, and this setting will be set for those services that were using the old SFU mod_auth_cas before the upgrade to CAS 5. If you want to use the old SFU mod_auth_cas with a new service, you either need to let us know to set that setting for your service, or you need to specify "CASValidateURL https://cas.sfu.ca/cas/p3/serviceValidate" to get the attributes that are needed by mod_auth_cas.

What needs to be done to upgrade to the new mod_auth_cas?

There are a number of good reasons to upgrade to the new mod_auth_cas, including allowing you to upgrade to the new, fully supported, Apache 2.4. The first thing to do before upgrading is to read Using mod_auth_cas at SFU to get an idea how the new module works and where to get it.

Once you have the new mod_auth_cas downloaded, built and installed, you need to make sure that you have set CASValidateURL to p3/serviceValidate like this:

CASValidateURL https://cas.sfu.ca/cas/p3/serviceValidate

The next step is to check if you have specified

Authtype Basic

when using mod_auth_cas. This was allowed in the old SFU mod_auth_cas so that you could use Apache basic authentication in conjunction with CAS when controlling access to a non-web application such as WebDAV. This is not supported in the new mod_auth_cas, but we have made available a simple authentication module mod_authn_cas which will handle this use case. See this page for information on mod_authn_cas.

Using "Basic" was also allowed in certain circumstances as equivalent to "CAS". If that was how it was being used, simply use "Authtype CAS" instead.

Next, check to see if you use 

AuthUserFile /path/to/.htpasswd

to point to a file containing userid/password entries. The old mod_auth_cas would let you use these .htpasswd files to specify IDs or maillists to control access. The new mod_auth_cas doesn't support these .htpasswd files, so see the following table for replacing items in the .htpasswd file with Require lines.

 

Line in .htpasswd file What it did Equivalent Require line in new mod_auth_cas
+userid
allow access to SFU userid

Require user userid

+!mail-list
allow access to members of mail-list

Require cas-attribute member:mail-list

userid password
allow access to made up ID
this is not supported in new mod_auth_cas

 

The final step is to replace the Require directives from the old mod_auth_cas with equivalent Require directives for the new mod_auth_cas. The following table should help.

 

Old mod_auth_cas New mod_auth_cas
Require valid-user
or
Require valid-sfu-user 

Require valid-user

Require user userid
or
Require sfu-user userid

Require user userid

Require user !mail-list

Require cas-attribute member:mail-list

Require valid-sfu-staff

Require cas-attribute sfuEduPersonAffiliation:staff

Require valid-sfu-faculty

Require cas-attribute sfuEduPersonAffiliation:faculty

Require valid-sfu-student

Require cas-attribute sfuEduPersonAffiliation:undergrad
Require cas-attribute sfuEduPersonAffiliation:grad

Required valid-alumni-user

Require cas-attribute sfuEduPersonAffiliation:alumnus