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:
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:
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?
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.
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.
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:
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/” 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?
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.
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:
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.
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.
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.