Implementing CAS with OOD

Trying to do a fresh install of OOD 2.0 on RockyLinux 8 VM using CAS for authentication. I did find some threads on this but it is dated and what I found there isn’t working. Try to list out what I have done. After install of Rocky, I did the following to install OOD:

dnf config-manager --set-enabled powertools
dnf install epel-release
dnf module enable ruby:2.7 nodejs:12
dnf install
dnf install ondemand

I then disabled selinux and rebooted the server. I setup SSL certs and opened up firewall ports for 80 and 443. I then downloaded, compiled and installed mod_auth_cas below:

dnf install openssl-devel.x86_64
dnf install libcurl-devel.x86_64
dnf install pcre-devel.x86_64
git clone -b v1.2 GitHub - apereo/mod_auth_cas: An Apache httpd module for integrating with Apereo CAS Server project. && cd mod_auth_cas
autoreconf -ivf
make install

Created /etc/httpd/conf.modules.d/01-cas.conf file with the following:
LoadModule auth_cas_module /usr/lib64/httpd/modules/

Then did:
mkdir /var/cache/httpd/mod_auth_cas
chown apache:apache /var/cache/httpd/mod_auth_cas
chmod 700 /var/cache/httpd/mod_auth_cas

Then created file /etc/httpd/conf.d/auth_cas.conf and put the following:
CASCookiePath /var/cache/httpd/mod_auth_cas/
CASLoginURL https://server.o.e/idp/profile/cas/login
CASValidateURL https://server.o.e/idp/profile/cas/serviceValidate

Lastly, configured OOD ood_portal.yml with these changes for SSL and this for the auth:

  • ‘AuthType CAS’
  • ‘Require valid-user’
  • ‘RequestHeader unset Authorization’

Then ran /opt/ood/ood-portal-generator/sbin/update_ood_portal and restarted httpd. The issue I’m seeing is that it looks like CAS is not getting defined in the OOD apache conf file. This is the error I’m seeing when trying to access the site:

[Tue Oct 11 14:00:12.940263 2022] [authn_core:error] [pid 28711:tid 140131461740288] [client] AH01796: AuthType openid-connect configured without corresponding module

In the apache conf file it has “AuthType openid-connect”. Why didn’t CAS get set?


Update: I manually changed the AuthType in the ood_portal.conf file to CAS. And was able to successfully hit our CAS service and get prompted for DUO auth. But then the page returns the following error:


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.

Not seeing anything useful in the httpd logs.

The OIDC issue where you have to edit the conf file directly may be related to ondemand-dex package. If you have the ondemand-dex package installed, we’ll choose some defaults (OIDC being one). So I’d check out if you have that package, and remove it if you do.

To your CAS issue - I’d suggest upping your log level to debug and using CASDebug on setting. (Their docs say you need LogLevel at debug for it to work, so be aware of that).

That said - you may need to enable CASScope as that could be blocking you from seeing anything.

Thank you. Not sure what the issue was with openid-connect being there, but after running the portal update again with some additions to the auth section it kept the CAS AuthType in place. I confirmed that ondemand-dex isn’t installed on the server.

I made change to the ood_portal.yml file in the Auth: section below:


  • ‘AuthType CAS’
  • ‘RequestHeader edit* Cookie “(^MOD_AUTH_CAS[^;](;\s)?|;\sMOD_AUTH_CAS[^;])” “”’
  • ‘RequestHeader unset Cookie “expr=-z %{req:Cookie}”’
  • ‘CASScope /’

From the thread, I found here. Did not change the behavior. I turned on debug and CASDebug and this is what i’m seeing. The error I’m seeing is this “curl_easy_perform() failed (), referer:” From the mod_auth_cas code, there should be an error string printed there but it is null it looks like. Might be bug code? I’m thinking that should have shown the curl command to validate the ticket?

Attaching the error logs here.
ondemand-logs.txt (11.7 KB)

This issue on mod_auth_cas may help. Seems like there could be certificate issue between the OOD server and the CAS server where the OOD server doesn’t like the CAS server’s certificate.

I’m not seeing that it is a certificate issue. I ran curl command after getting the ticket from the apache logs.

  • successfully set certificate verify locations:
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt
    CApath: /etc/pki/tls/certs
  • SSL certificate verify ok.
    < HTTP/1.1 200 200
    < Date: Wed, 12 Oct 2022 23:13:57 GMT
    < Server: Apache/2.4.38 (Debian)
    < Strict-Transport-Security: max-age=15768000
    < Cache-Control: no-store
    < Expires:
    < Set-Cookie: JSESSIONID=43A5F98824C80119723A8D29C1AD0C0A; Path=/idp; Secure; HttpOnly
    < Content-Type: text/html;charset=utf-8
    < Content-Length: 227
    < Vary: Accept-Encoding
<?xml version="1.0" encoding="UTF-8"?>

<cas:serviceResponse xmlns:cas=“”>
<cas:authenticationFailure code=“INVALID_TICKET”>

  • Connection #0 to host left intact

That shows certificates are good right? That last error I assume is due to reusing the ticket again?

Does the CASCertificatePath setting do anything for you? I’m wondering if there’s some difference between curl and what apache can use/see.

No changing the CASCertificatePath to either the folder path (/etc/pki/tls/certs) or the full path to the CA cert file doesn’t change anything (/etc/pki/tls/certs/ca-bundle.crt). The /etc/httpd/conf.d/auth_cas.conf file now looks like this:

CASDebug on
CASTimeout 43200
CASIdleTimeout 7200
CASCookiePath /var/cache/httpd/mod_auth_cas/
CASCertificatePath /etc/pki/tls/certs/ca-bundle.crt

Further debugging. Running tcpdump on my OnDemand server to see if any communications are being sent to the CAS servers. From what I’m seeing no attempts are being made to the CAS server. The way I understand the flow, my browser is doing the redirection, the OnDemand server tells my client to redirect to CAS server, and passes the referer of ondemand. Then my browser requests CAS server, and then CAS server tells my browser to redirect back to ondemand with the ticket attached.

I should only see communication from ondemand to CAS server when it does the curl to verify the ticket correct? From the logs I see where the curl_easy_perform() failed, makes since I’m not seeing any traffic to the CAS server from the ondemand server.

Any idea why the curl validation is failing? I have confirmed with our CAS admins my URL’s are all correct. At this point should I go to the mod_auth_cas user list? This looks to be a bug, since it’s not printing out any error on why the curl is failing.

My guess is (and this is only a guess) that since you’ve compiled from the source code you may have compiled against the wrong library. It appe

Looking at other tickets on the github repository I see stuff like this

MOD_AUTH_CAS: curl_easy_perform() failed (Peer's Certificate issuer is not recognized.)

Note that your error message has no message after failed - empty parentheses ().

MOD_AUTH_CAS: curl_easy_perform() failed ()

I’d suggest two things: (1) opening a ticket on GitHub - apereo/mod_auth_cas: An Apache httpd module for integrating with Apereo CAS Server project. as you may get a response there. (2) maybe recompiling with the --with-apxs=/usr/bin/apxs flag (IDK if that’s the right APXS location for you). The second suggestion is really a guess. I’m not even 50% sure it’s a solution.

Building mod_auth_cas with apxs didn’t change anything. I have submitted an issue to the apereo list. Maybe will get an answer back. But I believe the issue is in the curl libs with RockyLinux 8.
For a test, I built CentOS7 VM and got OnDemand to work without issue using mod_auth_cas.

I don’t like the CentOS7work around as it will be EOL by 2024.

Well, a good thing bad thing just happened. I thought I had this down to an issue with libcurl version when CAS just worked with CentOS 7. I went back to the RockyLinux VM and compiled an older version of curl and compiled mod_auth_cas against that. And it worked! Great, it is an issue with libcurl version, or so I thought. I went to find the newest version of libcurl before it broke again. Well, I hit the latest version of libcurl and it is still working!! I can’t tell you what changed, from last week when it was not working or communicating with the CAS servers. Rebooted the VM and still working. I even went back and compiled mod_auth_cas with the standard packaged openssl with RockyLinux and it’s still working. So bad thing is I’m not sure what changed to have things working now.
Very confused.