Implementing authentication via CAS

Is anyone able to provide guidance on editing ood_portal.yml to support CAS authentication? I tried a few ideas that did not work, based on our implementation test outlined below – which provided a successful test.

We have implemented CAS through a download and build of mod_auth_cas from this repo: https://github.com/apereo/mod_auth_cas. The service was configured in the system, and then we made ad-hoc edits to the existing ood configuration in /opt/rh/httpd24/root/etc/httpd/conf.d to verify that the service would recognize OoD.

This was realized through direct edit of the ood-portal.conf, and by creating a cas.conf file in /opt/rh/httpd24/root/etc/httpd/conf.d

In reviewing the differences between ood-portal.conf in the successful test case, and the ‘standard’ configuration, the meaningful differences are few:

<<VirtualHost [host-public-ip]:80>
><VirtualHost *:80>

87c87
< AuthType CAS
> AuthType Basic

89c89
< #AuthUserFile “/opt/rh/httpd24/root/etc/httpd/.htpasswd”
> AuthUserFile “/opt/rh/httpd24/root/etc/httpd/.htpasswd”

Only setting the VIrtualHost through ood_config.yml is unclear – the other two values are somewhat documented in the code. I tried to set the public IP using the ‘servername’ keyword, and then also ‘virtualhost’, and in both cases the result was ‘VIrtualHost *:80’

Source: Originally posted by E.M. Dragowsky in the ood-users mailing list.

Having VirtualHost *:80 should be fine as long as ServerName matches the name that is being used to access OOD. For our systems we set “servername” in ood_portal.yml to the DNS name of our instance that is used to access the web interface, not the IP. We don’t define virtualhost.

Example:

listen_addr_port:
- '443'
- '80'
servername: ood.osc.edu
port: '443'

The above example assumes your using SSL, if you’re not (not recommended) then you can ignore the values that have 443.

For the auth block you’ll want to just have something like this:

auth:
- 'AuthType CAS'
- 'Require valid-user'
- 'RequestHeader unset Authorization'

Those three should be enough to require a valid CAS user if you have properly configured mod_auth_cas. I don’t think AuthName will get used because that typically is what populates basic auth dialogue box. Every time I’ve used CAS the request redirects to CAS login form so you won’t get the basic auth dialogue box.

Are there any good instructions for setting up ood to use cas? We’re told we have to use cas at a minimum and saml would be preferred.

Would you post a copy of your cas.conf? Of course removing passwords etc.

Please take a look at https://listsprd.osu.edu/pipermail/ood-users/2017-November/000085.html and https://listsprd.osu.edu/pipermail/ood-users/2017-November/000086.html

If you need any more guidance I can reach out to sites I know that use CAS and see if they can post here.

Great! Thanks! I’ll look through that and see if I have any other questions.

When we try and make mod_auth_cas, we get the following error. We do have libtool installed on the system.

make all-recursive
make[1]: Entering directory /root/mod_auth_cas/mod_auth_cas' Making all in src make[2]: Entering directory/root/mod_auth_cas/mod_auth_cas/src’
/opt/rh/httpd24/root/usr/bin/apxs -c -lpcre -lssl -lcrypto -Wc," -D_LARGEFILE64_SOURCE -g -O2 -Wall -Wextra -Wdeclaration-after-statement -Wformat -Wformat-security -Wmissing-declarations -Wno-unused-parameter -Wpointer-arith -Wstrict-prototypes " -Wl," -lcurl -lpcre -lssl -lcrypto " mod_auth_cas.c cas_saml_attr.c
/apr-1/build/libtool --silent --mode=compile gcc -std=gnu99 -prefer-pic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DLINUX -D_REENTRANT -D_GNU_SOURCE -pthread -I/opt/rh/httpd24/root/usr/include/httpd -I/opt/rh/httpd24/root/usr/include/apr-1 -I/opt/rh/httpd24/root/usr/include/apr-1 -I/opt/rh/httpd24/root/usr/include -D_LARGEFILE64_SOURCE -g -O2 -Wall -Wextra -Wdeclaration-after-statement -Wformat -Wformat-security -Wmissing-declarations -Wno-unused-parameter -Wpointer-arith -Wstrict-prototypes -c -o mod_auth_cas.lo mod_auth_cas.c && touch mod_auth_cas.slo
sh: /apr-1/build/libtool: No such file or directory
apxs:Error: Command failed with rc=8323072
.
make[2]: *** [mod_auth_cas.la] Error 1
make[2]: Leaving directory /root/mod_auth_cas/mod_auth_cas/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/root/mod_auth_cas/mod_auth_cas’
make: *** [all] Error 2

Also, in the directions is says to use autoreconf which is not on the system, but autoconf is.

autoreconf being missing can be ignored. This was a shell issue.

Here is how we set up CAS (RHEL7, OOD 1.3). In addition to httpd24-httpd-devel, you will probably need autoconf, automake, and libtools installed. The following is run as root, though not everything need be.

# CAS
git clone -b v1.1 https://github.com/apereo/mod_auth_cas.git && cd mod_auth_cas
scl enable httpd24 -- autoreconf -f -i
scl enable httpd24 -- ./configure --prefix=/opt/rh/httpd24/root/etc/httpd/modules
scl enable httpd24 -- make install

echo "LoadModule auth_cas_module modules/mod_auth_cas.so" > /opt/rh/httpd24/root/etc/httpd/conf.modules.d/yalehpc-cas.conf

# make CAS cookie dir
mkdir /opt/rh/httpd24/root/var/cache/httpd/mod_auth_cas
chown apache:apache /opt/rh/httpd24/root/var/cache/httpd/mod_auth_cas
chmod 700 /opt/rh/httpd24/root/var/cache/httpd/mod_auth_cas

# configure CAS
cat << EOF > /opt/rh/httpd24/root/etc/httpd/conf.d/auth-config.conf
CASCookiePath /opt/rh/httpd24/root/var/cache/httpd/mod_auth_cas/
CASLoginURL https://secure.its.yale.edu/cas/login
CASValidateURL https://secure.its.yale.edu/cas/serviceValidate
EOF

We copy the ssl certs on this host directly for now. Here is an excerpt from our /etc/ood/config/ood_portal.yml:

servername: ood-farnam.hpc.yale.edu
ssl:
  - 'SSLCertificateFile "/etc/pki/tls/certs/ood-farnam.crt"'
  - 'SSLCertificateKeyFile "/etc/pki/tls/private/ood-farnam.key"'
  - 'SSLCertificateChainFile "/etc/pki/tls/certs/ood-farnam-interm.crt"'
auth:
  - 'AuthType CAS'
  - 'Require valid-user'
  - 'RequestHeader unset Authorization'

Then

/opt/ood/ood-portal-generator/sbin/update_ood_portal
systemctl restart httpd24-httpd.service httpd24-htcacheclean.service

You shouldn’t have to directly edit yourhttpd/conf.d, at least we don’t.

2 Likes

This is how we install mod_auth_cas on CentOS 7

git clone https://github.com/klausdieterkrannich/mod_auth_cas
autoreconf
./configure --prefix=/opt/rh/httpd24/root/etc/httpd/modules --with-apxs=/opt/rh/httpd24/root/usr/bin/apxs
make install

You will need apr-devel installed for building mod_auth_cas.

Other things are very similar to what Ben has provided, with minor difference on our ood_portal.yml

port: 443
servername: 'portal-terra.hprc.tamu.edu'
ssl:
  - SSLProtocol              all -SSLv3 -TLSv1 -TLSv1.1
  - 'SSLCertificateFile      "/etc/pki/tls/certs/portal-terra_hprc_tamu_edu_cert.cer"'
  - 'SSLCertificateKeyFile   "/etc/pki/tls/private/portal-hprc.key"'
  - 'SSLCertificateChainFile "/etc/pki/tls/certs/portal-terra_hprc_tamu_edu_interm.cer"'
auth:
  - 'AuthType CAS'
  - 'Require group ood'
  - 'AuthGroupFile /sw/hprc/local/etc/ood/ood.cas'
  - 'RequestHeader edit* Cookie "(^MOD_AUTH_CAS[^;]*(;\s*)?|;\s*MOD_AUTH_CAS[^;]*)" ""'
  - 'RequestHeader unset Cookie "expr=-z %{req:Cookie}"'
  - 'CASScope /'
logout_redirect: 'https://cas.tamu.edu/cas/logout'

Also @wew please check and verify you have the apr-devel package installed.

Another site using CentOS Linux 7.5.1804 just cloned the master branch of mod_auth_cas and was able to build successfully using:

scl enable httpd24 -- ./configure
make

On that site’s test box /apr-1/build/libtool shows up as /usr/lib64/apr-1/build/libtool which which comes from apr-devel

We’re having issues getting CAS working. When we following all the examples given for CAS, the server starts up fine and does not appear to have any configuration issues but when we try and log in we get the following:

Unauthorized

This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn’t understand how to supply the credentials required.

In the log files we see:
[Tue Nov 13 10:34:46.242536 2018] [:error] [pid 26837] [client 134.114.32.3:56106] MOD_AUTH_CAS: error parsing CASv2 response:
XML parser error code: syntax error (2)
[Tue Nov 13 10:36:44.219649 2018] [:error] [pid 26836] [client 134.114.32.3:56148] MOD_AUTH_CAS: error parsing CASv2 response:
XML parser error code: syntax error (2), referer: https://cas.nau.edu/cas/login?service=https%3A%2F%2Fondemand.hpc.nau.edu%2F
pun%2fsys%2fdashboard
[Tue Nov 13 10:54:24.426463 2018] [:error] [pid 26943] [client 134.114.32.3:56388] MOD_AUTH_CAS: error parsing CASv2 response:
XML parser error code: syntax error (2)
[Tue Nov 13 10:55:18.729512 2018] [:error] [pid 26944] [client 134.114.32.3:56411] MOD_AUTH_CAS: error parsing CASv2 response:
XML parser error code: syntax error (2), referer: https://cas.nau.edu/cas/login?service=https%3A%2F%2Fondemand.hpc.nau.edu%2F
pun%2fsys%2fdashboard

I’m not sure what we are missing at this point.

We checked the CAS server and we are getting tickets and valid logins from that side but ondemand gives us the Unauthorised page. Any ideas where to look to fix this on the ondemand side?

We were finally able to get things working. As a note, we also had to chown the following to apache: /opt/rh/httpd24/root/etc/httpd/mod_auth_cas

Once that was also owned then things began to work with the directions given by b.evans.

It would really help if cas or preferably saml was supported out of the box.

Just going to leave this here in case anyone else is interested: We’re deploying OOD 2.0 on RHEL 8.4 with CAS authentication. The solution from @b.evans is still valid, except that OOD 2.0 is no longer using software collections, so the httpd paths are standard system paths.

To get an idea of the differences, this article worked for us, up through the “Settings for httpd” section (with the exception that we did not need the CASCertificatePath line).