CAS incorrect redirection behind reverse proxy
207 views
Skip to first unread message
Cliff Ingham
Apr 3, 2018, 2:40:31 PM4/3/18
to CAS Community
Is there something I'm missing when setting CAS up behind a reverse proxy? CAS is rewriting the hostnames of the service URLs when doing the redirection.
When both CAS and a web application using CAS authentication are behind the same reverse proxy, then CAS rewrites the service URL when redirecting back to the web application during authentication.
CAS authentication works successfully when not behind any reverse proxy. Also, it works successfully, in CAS and the web application are behind two different reverse proxies. It's only if they're both behind the same reverse proxy that it does not work as expected.
Example
CAS at https://cas.host.org/cas
Web Application at https://app.host.org/app
Authentication works as expected when visting https://app.host.org/app. The app redirects to CAS at https://cas.host.org/cas and cas redirects back as expected.
Drop CAS behind a reverse proxy at https://proxy.host.org/cas. Authentication still works as expected when visiting https://app.host.org/app and doing the auth through https://proxy.host.org
You can even drop the App behind a different proxy and it will work as expected.
Visit https://proxy-two.host.org/app and do auth through either https://proxy.host.org/cas or https://cas.host.org/cas and it works as expected.
However
If you reverse proxy the app and CAS behind the same host, then CAS will always rewrite the service URL for the app during the redirection step. It rewrites the service URL to the reverse proxy hostname, even if you came from the original hostname for the app.
Set up a reverse proxy at https://proxy.host.org/app
But when you still visit https://app.host.org/app (This not accessing it through the reverse proxy, even though the reverse proxy is still configured). Do auth through https://proxy.host.org/cas and when CAS sends the 302 redirect header, it sends https://proxy.host.org/app, instead of https://app.host.org/app as expected.
When both CAS and a web application using CAS authentication are behind the same reverse proxy, then CAS rewrites the service URL when redirecting back to the web application during authentication.
CAS authentication works successfully when not behind any reverse proxy. Also, it works successfully, in CAS and the web application are behind two different reverse proxies. It's only if they're both behind the same reverse proxy that it does not work as expected.
Example
CAS at https://cas.host.org/cas
Web Application at https://app.host.org/app
Authentication works as expected when visting https://app.host.org/app. The app redirects to CAS at https://cas.host.org/cas and cas redirects back as expected.
Drop CAS behind a reverse proxy at https://proxy.host.org/cas. Authentication still works as expected when visiting https://app.host.org/app and doing the auth through https://proxy.host.org
You can even drop the App behind a different proxy and it will work as expected.
Visit https://proxy-two.host.org/app and do auth through either https://proxy.host.org/cas or https://cas.host.org/cas and it works as expected.
However
If you reverse proxy the app and CAS behind the same host, then CAS will always rewrite the service URL for the app during the redirection step. It rewrites the service URL to the reverse proxy hostname, even if you came from the original hostname for the app.
Set up a reverse proxy at https://proxy.host.org/app
But when you still visit https://app.host.org/app (This not accessing it through the reverse proxy, even though the reverse proxy is still configured). Do auth through https://proxy.host.org/cas and when CAS sends the 302 redirect header, it sends https://proxy.host.org/app, instead of https://app.host.org/app as expected.
Uxío Prego
Apr 3, 2018, 2:56:58 PM4/3/18
to CAS Community
I can't tell why, but I've known of ancient CAS deployments where the CAS application sits behind the proxy configured at its very own third level domain, where CAS is the only accessible application... or meaningful application... depending on the existing applications ecosystem's structure.
In other words; if you can not fix it in time, roll forward that way without fixing anything.
Uxío Prego
Madiva Soluciones
CL / SERRANO GALVACHE 56
BLOQUE ABEDUL PLANTA 4
28033 MADRID
+34 917 56 84 94
www.madiva.com
CL / SERRANO GALVACHE 56
BLOQUE ABEDUL PLANTA 4
28033 MADRID
+34 917 56 84 94
www.madiva.com
www.bbva.com
The activity of email inboxes can be systematically tracked by colleagues, business partners and third parties. Turn off automatic loading of images to hamper it.
The activity of email inboxes can be systematically tracked by colleagues, business partners and third parties. Turn off automatic loading of images to hamper it.
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscribe@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/a25b9e6d-f042-46e8-9865-c0b0fb97225a%40apereo.org.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages