Session Hook, reverse proxy and shibboleth

[avillanueva]

Referencing this post: Configuring SAML SSO with Reverse Proxy , when we last left our main characters, we still a question why the sessionHook was reporting that the windchill domain was not matching the request and target hosts:

I still have issues with the sessionHook.jsp for which I have a PTC ticket on. Take note of this debug logger (sso.shibboleth.sessionHook). This was key to it complaining about the different domains. I was able to code around the issue but intend to return to OOTB hook. For now, its working as it should. I will try and collect my notes and write up something clearer.

There is a check in the sessionHook jsp files that has a flag isValidUsage and if hostnames do not match, you get an error. I believe this to be a security check. I just got off a call with PDSVision and we traced the cause back to the proxy so I want to make sure I document it here for others.

[avillanueva · Accepted solution]

Here is what you see when turning on debug logging:

2024-07-18 14:03:48,235 DEBUG [ajp-nio-127.0.0.1-8012-exec-2] sso.shibboleth.sessionHook username - Query Parameter - return = https://<proxy external hostname>/Shibboleth.sso/SAML2/POST?hook=1&target=ss%3Amem%3Ab452c5a99e22e5fd24d63489eac04a4e802ee91aa4d2ed049476c853b0784e75
2024-07-18 14:03:48,235 DEBUG [ajp-nio-127.0.0.1-8012-exec-2] sso.shibboleth.sessionHook username - Query Parameter - target = https://<proxy external hostname>/Windchill/app/
2024-07-18 14:03:48,236 DEBUG [ajp-nio-127.0.0.1-8012-exec-2] sso.shibboleth.sessionHook username - Windchill Domain Name = <internal pdmlink hostname>

So in our setup, we installed Windchill with a generic virtual name and put a reverse proxy in front to make it a unique instance to the work. What this allowed for PDSVision to clone and stamp out Windchill instances with all the same names but use the proxy to make them unique.  We struggled to see where it was getting the internal name from. On the proxy, we traced it to the ProxyPass settings where the proxy redirects requests to the PTC. HTTPServer. In this case, we are doing SSL offloading since its on the same server (might change that at some point. 

# Windchill Reverse Proxy Additions and Settings
RewriteEngine on
SSLProxyEngine on
ProxyPass /Windchill/ http://<external hostname>:8880/Windchill/
ProxyPassReverse /Windchill/ http://<external hostname>:8880/Windchill/
ProxyPass /Windchill-WHC http://<external hostname>:8880/Windchill-WHC
ProxyPassReverse /Windchill-WHC http://<external hostname>:8880/Windchill-WHC
ProxyPass /Windchill-WHC/ http://<external hostname>:8880/Windchill-WHC/
ProxyPassReverse /Windchill-WHC/ http://<external hostname>:8880/Windchill-WHC/
RewriteRule ^/Windchill$ /Windchill/ [R]

#Shibboleth Reverse Proxy Additions and Settings
ProxyPass        /Shibboleth.sso/ http://<external hostname>:8880/Shibboleth.sso/
ProxyPassReverse /Shibboleth.sso/ http://<external hostname>:8880/Shibboleth.sso/
ProxyPass        /reauthsecure/Shibboleth.sso/ http://<external hostname>:8880/reauthsecure/Shibboleth.sso/
ProxyPassReverse /reauthsecure/Shibboleth.sso/ http://<external hostname>:8880/reauthsecure/Shibboleth.sso/

# Force requests to Windchill
RedirectMatch ^/$ https://<external hostname>/Windchill/
RedirectMatch ^/windchill$ https://<external hostname>/Windchill/

Previously, we had these directed to the internal hostname but this the source of the issue. Changing this made everything line up properly. It is able to find its way to the PTC Webserver since we are not using SSL (https) and the port is changed to 8880. I still have a question whether there are better setups or what if the proxy was on a different host entirely.  That is for another day.