# Implementing CAS with OOD

**URL:** <https://discourse.openondemand.org/t/implementing-cas-with-ood/2312>\
**Category:** Get Help\
**Tags:** question\
**Created:** [October 11, 2022, 9:16pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312 "2022-10-11T21:16:11Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![cj.keist](https://avatars.discourse-cdn.com/v4/letter/c/a698b9/32.png) [@cj.keist](https://discourse.openondemand.org/u/cj.keist)\
**Post date:** [October 11, 2022, 9:16pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/1 "2022-10-11T21:16:11Z")

</div>

Hello,  
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 [https://yum.osc.edu/ondemand/2.0/ondemand-release-web-2.0-1.noarch.rpm](https://yum.osc.edu/ondemand/2.0/ondemand-release-web-2.0-1.noarch.rpm)  
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.](https://github.com/apereo/mod_auth_cas.git) && cd mod\_auth\_cas  
autoreconf -ivf  
./configure  
make  
make install

Created /etc/httpd/conf.modules.d/01-cas.conf file with the following:  
LoadModule auth\_cas\_module /usr/lib64/httpd/modules/mod\_auth\_cas.so

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](https://server.o.e/idp/profile/cas/login)  
CASValidateURL [https://server.o.e/idp/profile/cas/serviceValidate](https://server.o.e/idp/profile/cas/serviceValidate)

Lastly, configured OOD ood\_portal.yml with these changes for SSL and this for the auth:  
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 10.214.120.171:57206] AH01796: AuthType openid-connect configured without corresponding module

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

Thanks…

---

<div class="post-metadata">

**Author:** ![cj.keist](https://avatars.discourse-cdn.com/v4/letter/c/a698b9/32.png) [@cj.keist](https://discourse.openondemand.org/u/cj.keist)\
**Post date:** [October 11, 2022, 10:37pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/2 "2022-10-11T22:37:02Z")

</div>

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:

# 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.

Not seeing anything useful in the httpd logs.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [October 12, 2022, 4:26pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/3 "2022-10-12T16:26:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![cj.keist](https://avatars.discourse-cdn.com/v4/letter/c/a698b9/32.png) [@cj.keist](https://discourse.openondemand.org/u/cj.keist)\
**Post date:** [October 12, 2022, 8:13pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/4 "2022-10-12T20:13:39Z")

</div>

Jeff,  
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:

auth:

- ‘AuthType CAS’
- ‘RequestHeader edit\* Cookie “(^MOD\_AUTH\_CAS[^;]_(;\s_)?|;\s_MOD\_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: [https://cas.oregonstate.edu/](https://cas.oregonstate.edu/)” 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](https://discourse.openondemand.org/uploads/short-url/eogrrdG0DAT4kIZh3uSTaBnSoNU.txt) (11.7 KB)

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [October 12, 2022, 8:51pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/5 "2022-10-12T20:51:01Z")

</div>

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.

> <https://github.com/apereo/mod_auth_cas/issues/184>
>
> I have a CentOS 7 machine using Apache \`2.4.43\` and latest \`mod\_auth\_cas\` compil…ed against \`master\`.
> 
> As soon as I install full chain certs for my server, \`mod\_auth\_cas\` rejects all requests to protected locations with a \`401 (Unauthorized)\` response.
> 
> \> \*\*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.
> 
> Debug logs show a very weird error being returned from \`curl\_easy\_perform\` when calling \`/serviceValidate\`.
> 
> \`\`\`sh
> \[Mon Apr 06 11:21:22.592697 2020\] \[:debug\] \[pid 14076:tid 140007603758848\] mod\_auth\_cas.c(2058): \[client 10.10.12.10:29500\] Entering cas\_authenticate()
> \[Mon Apr 06 11:21:22.592704 2020\] \[:debug\] \[pid 14076:tid 140007603758848\] mod\_auth\_cas.c(652): \[client 10.10.12.10:29500\] Modified r-\>args (now '')
> \[Mon Apr 06 11:21:22.592784 2020\] \[:debug\] \[pid 14076:tid 140007603758848\] mod\_auth\_cas.c(1761): \[client 10.10.12.10:29500\] entering getResponseFromServer()
> \[Mon Apr 06 11:21:22.592916 2020\] \[:debug\] \[pid 14076:tid 140007603758848\] mod\_auth\_cas.c(580): \[client 10.10.12.10:29500\] CAS Service 'https%3a%2f%2fportal.domain.io%2f'
> \[Mon Apr 06 11:21:22.717511 2020\] \[:debug\] \[pid 14076:tid 140007603758848\] mod\_auth\_cas.c(1830): \[client 10.10.12.10:29500\] MOD\_AUTH\_CAS: curl\_easy\_perform() failed (@@@@@@@@@@@@@@@@\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[ )
> \`\`\`
> 
> I tried reproducing the same using plain \`curl\` command line from the host, but couldn't.
> 
> \`\`\`sh
> curl -vv --capath /etc/ssl/certs 'https://cas.domain.io/cas/serviceValidate?ticket=ST-619-n1lIuKDqqy75NRboowbbNJAT2As-cas0&service=https%3a%2f%2fportal.domain.io%2f'
> 
> \* About to connect() to cas.domain.io port 443 (#0)
> \* Trying 10.1.15.100...
> \* Connected to cas.domain.io (10.1.15.100) port 443 (#0)
> \* Initializing NSS with certpath: sql:/etc/pki/nssdb
> \* failed to load '/etc/ssl/certs/Makefile' from CURLOPT\_CAPATH
> \* failed to load '/etc/ssl/certs/make-dummy-cert' from CURLOPT\_CAPATH
> \* failed to load '/etc/ssl/certs/renew-dummy-cert' from CURLOPT\_CAPATH
> \* CAfile: /etc/pki/tls/certs/ca-bundle.crt
> CApath: /etc/ssl/certs
> \* SSL connection using TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384
> \* Server certificate:
> \* subject: CN=\*.domain.io,OU=Domain Control Validated
> \* start date: Jul 25 23:58:34 2019 GMT
> \* expire date: Jul 25 23:58:34 2020 GMT
> \* common name: \*.domain.io
> \* issuer: CN=AlphaSSL CA - SHA256 - G2,O=GlobalSign nv-sa,C=BE
> \> GET /cas/serviceValidate?ticket=ST-619-n1lIuKDqqy75NRboowbbNJAT2As-cas0&service=https%3a%2f%2fportal.domain.io%2f HTTP/1.1
> \> User-Agent: curl/7.29.0
> \> Host: cas.domain.io
> \> Accept: \*/\*
> 
> \<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'\>
> \<cas:authenticationFailure code="INVALID\_TICKET"\>Ticket &#39;ST-619-n1lIuKDqqy75NRboowbbNJAT2As-cas0&#39; not recognized\</cas:authenticationFailure\>
> \</cas:serviceResponse\>
> \`\`\`
> 
> Needless to say, the ticket was no longer valid - but the server \_is\_ reachable from the host and certs look good to me.
> 
> I also tried setting \`CASCertificatePath\` pointing to the CA certs, but that leads to a different issue.
> 
> \`\`\`sh
> \[Mon Apr 06 10:56:18.621870 2020\] \[:error\] \[pid 13811:tid 140217193326336\] \[client 10.10.12.10:7161\] MOD\_AUTH\_CAS: Could not process Certificate Authority: /etc/ssl/certs/ca-bundle.crt
> \`\`\`
> 
> Any ideas on what would cause the above? Many thanks.

---

<div class="post-metadata">

**Author:** ![cj.keist](https://avatars.discourse-cdn.com/v4/letter/c/a698b9/32.png) [@cj.keist](https://discourse.openondemand.org/u/cj.keist)\
**Post date:** [October 12, 2022, 11:21pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/6 "2022-10-12T23:21:57Z")

</div>

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=“[http://www.yale.edu/tp/cas](http://www.yale.edu/tp/cas)”\>  
\<cas:authenticationFailure code=“INVALID\_TICKET”\>  
E\_TICKET\_EXPIRED  
\</cas:authenticationFailure\>  
\</cas:serviceResponse\>

- Connection #0 to host login.oregonstate.edu left intact

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

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [October 13, 2022, 1:22pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/7 "2022-10-13T13:22:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![cj.keist](https://avatars.discourse-cdn.com/v4/letter/c/a698b9/32.png) [@cj.keist](https://discourse.openondemand.org/u/cj.keist)\
**Post date:** [October 13, 2022, 3:17pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/8 "2022-10-13T15:17:57Z")

</div>

Jeff,  
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  
CASLoginURL [https://server.oregonstate.edu/idp/profile/cas/login](https://server.oregonstate.edu/idp/profile/cas/login)  
CASValidateURL [https://server.oregonstate.edu/idp/profile/cas/serviceValidate](https://server.oregonstate.edu/idp/profile/cas/serviceValidate)

---

<div class="post-metadata">

**Author:** ![cj.keist](https://avatars.discourse-cdn.com/v4/letter/c/a698b9/32.png) [@cj.keist](https://discourse.openondemand.org/u/cj.keist)\
**Post date:** [October 13, 2022, 11:11pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/9 "2022-10-13T23:11:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [October 14, 2022, 1:24pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/10 "2022-10-14T13:24:27Z")

</div>

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

```auto
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 ().

```auto
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.](https://github.com/apereo/mod_auth_cas) 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.

---

<div class="post-metadata">

**Author:** ![cj.keist](https://avatars.discourse-cdn.com/v4/letter/c/a698b9/32.png) [@cj.keist](https://discourse.openondemand.org/u/cj.keist)\
**Post date:** [October 14, 2022, 11:37pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/11 "2022-10-14T23:37:35Z")

</div>

Jeff,  
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.

---

<div class="post-metadata">

**Author:** ![cj.keist](https://avatars.discourse-cdn.com/v4/letter/c/a698b9/32.png) [@cj.keist](https://discourse.openondemand.org/u/cj.keist)\
**Post date:** [October 17, 2022, 6:15pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/12 "2022-10-17T18:15:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex015/uploads/osc/original/2X/b/bae70bd0ed39a3ae769c2108155f4cb3e9da8385.png) [@system](https://discourse.openondemand.org/u/system)\
**Post date:** [April 15, 2023, 6:16pm UTC](https://discourse.openondemand.org/t/implementing-cas-with-ood/2312/13 "2023-04-15T18:16:35Z")

</div>

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.