-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not Redirecting to serviceValidate #145
Comments
You should post the debug logs from mod_auth_cas here. They should tell us what we need to know.
There is no redirect for serviceValidate here. mod_auth_cas directly communicates with the CASValidateURL to validate the CAS ticket. Once that is complete, a redirect is sent to the browser to remove the ticket parameter from the URL. See the CAS protocol diagram here: https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol.html Post your debug logs and we'll go from there. |
I set the login and validate URLs back to their proper values, took the output from Please let me know if this is sufficient. |
I should have noticed this before. The ticket:
contains characters that are not allowed by validCASTicketFormat(), which creates a redirect loop. You can either modify your CAS server to send different STs, or modify mod_auth_cas to accept those characters. https://github.com/apereo/mod_auth_cas/blob/v1.1/src/mod_auth_cas.c#L690 If anyone can find a link to the set of characters in a valid CAS ST, that would be useful. #134 is related. |
I changed the However, I am now getting a 401 Unauthorized error.
Is there anything else that I would need to change for Edit: excerpt from error_log
|
Is that the last entry in the error log? The next thing that should be printed is the server response. If there was no response, you'll get a 401. Based on what you've said here about your setup, I expect you're getting stuck on the service validation, which is done by mod_auth_cas and not the user. Check the webserver logs on your intermediary site. I expect you'll see the request from mod_auth_cas to the CASValidateURL. |
Yes, that's the last entry of in the error log; it's denying access before calling I checked the CAS logs, and could not find any entries whatsoever when attempting to access the restricted directory, so I don't think a request is being made. |
What happens when you use the actual /serviceValidate URL of your CAS server for CASValidateURL? |
I have been using the actual serviceValidate URL. CAS does not show in the logs that a request was ever made. Visiting the serviceValidate URL in a browser does create logs. |
I would expect either a curl error in your logs or a validation response. From the line numbers, you are using v1.1, right? Are you comfortable modifying the source to add more debug messages? I can help you with this if you'd like. |
I'm not sure how to check what version I'm using, but yes I'd be comfortable with modifying the source. Just let me know where to put the debug messages. |
Try this branch (based on master) and post your logs: https://github.com/dhawes/mod_auth_cas/tree/issue-145-service-validate |
So, there would appear to be an issue with the CAS certificate. It should be noted that I was not the one who initially created this system; it was created by another group who left little to no documentation. I'm not entirely sure what the |
I'd expect it's a Java keystore. You can export the certs from there, but honestly I would just:
, copy the certs into a file called cachain.pem, and then:
|
I did the following:
And entered the path to that file into the Are there any specific permissions I should be assigning the keychain? This is what it currently is:
|
My bad, the certificate file was in a directory that apache could not access. I'm now getting this error:
Edit: moving the original
|
Sounds like a simple CA trust issue now. You didn't use |
I tried with I copied the keychain that apache itself was using into an accessible directory and linked that, and now it's working fine 🎉 Obviously it's not a very succinct solution as it'll break when the cert needs renewing, but I can deal with that on my own. Thank you so much for all your help! I really appreciate you taking the time out of your day to help me. I would not have been able to figure this out on my own. Thanks! |
Excellent, I'm glad it's all working now. This wasn't my best troubleshooting ever. I should have noticed the ST characters off the bat and I wish I had noted the .keystore file, but we got there eventually, right? ;) |
Nah you were fine! I didn't notice those either ;3 |
Hello. I'm trying to use
mod_auth_cas
on a CentOS Apache server (httpd) v2.4.6 to restrict access to a directory.The Problem
When accessing the restricted directory, it redirects me to the
login
page without issue. When redirecting from thelogin
page back to the restricted directory (with the token), it is supposed to redirect once more to theserviceValidate
with the service parameter, as well as the newly obtained token parameter. However, it instead redirects back to thelogin
page, creating an infinite loop of redirects. The service parameter gets recreated every time with a longer length. For example, with a configuration that links the login and validate URLs to the proper URLs, this is the last URL generated before the browser stops:Configuration
mod_auth_cas
is configured as follows:https://some.site/login.html
andhttps://some.site/validate.html
both redirect to a page which allows me to process redirects step-by-step. It displays the GET parameters in the URL, displays whether the redirect originated fromlogin
orvalidate
, and provides buttons to go to thelogin
andserviceValidate
pages. For example:Debugging Procedure
As mentioned in the configuration section, I have set up an intermediary site to ease the process of redirects. The earlier screenshot refers to how the site appears when you first attempt to access the restricted directory. Next, the
login
button is pressed to generate a token. However, this is the response:As you can see, the token is successfully generated. However we're redirected back to the login endpoint, which puts the token into the service parameter. Clicking validate is no good, as the token parameter is missing, and clicking the login button again results in this:
This illustrates the redirect loop experienced.
Conclusion
Any help with resolving this issue would be greatly appreciated, as I've been trying to figure this out for several weeks. If any more information is required, I will be more than happy to provide it. Thank you in advance!
The text was updated successfully, but these errors were encountered: