Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

[Aaron Roots]

Hi all,

I don't believe there is anything to be done on the Shibboleth side of things – but I wanted to let others know and perhaps someone will have some info that I don’t. But I am looking to log a bug with Apple.

So this is an issue that has popped up with the latest version of Safari for OSX (5.1.5 released March 26th) and one of our Shibboleth setups. I have included the diagram for ease of visualisation (http://moshpit.net.au/images/ReverseProxy.png) – the dashed lines are the Shibboleth SSO process through the browser (and not indicative of actual communication between the servers and the IdP). The reason we have the reverse proxy is because the permissions on the intranet are user controlled and we have had confidential data exposed to the internet previously due to user misconfiguration – so the reverse proxy is a way of enforcing a minimum level of authentication before getting access to internal resources without using a VPN and still allowing users to control access.

The reverse proxy is set up with the Intranet URL and an SP under https://intranet.example.com/Shibboleth-proxy.sso/ and uses apache mod_proxy (excerpt of the config below)
The intranet is set up with the Intranet URL and an SP under https://intranet.example.com/Shibboleth.sso/
The load balancer/site selector will direct external traffic to the Reverse Proxy – the reverse proxy makes request with an internal address and the whole process just works

What appears to be occurring with the new Safari - is that there are 2 form POSTs that occur automatically (using javascript) from the IdP in the whole process of gaining access to the Intranet (one to the Reverse Proxy and one to the Staff Intranet) - the latest version of Safari is submitting the contents of the first POST both times – instead of the expected behaviour of submitting the contents of the second form on the second POST. You can see this definitely occurring when you trace the traffic.

So a session is successfully created with the Reverse Proxy and then the Intranet throws a Binding error because it is receiving post data for Shibboleth-proxy.sso instead of Shibboleth.sso. If I try and access the original URL again – I will get through because there is a existing Session with the Reverse Proxy and it then only needs to do a single POST to the Intranet (which then has the correct data). If I switch off javascript and click the submit buttons manually – the whole process works fine. Every other browser works fine as well (including previous versions of Safari and Safari for iOS).

I was hoping to be able to reproduce the issue with a simple PHP application and using redirects and javascript – therefore eliminating Shibboleth from the equation but unfortunately I have been unsuccessful so far – so believe I may be missing something else in the process as well. Maybe it's related to mod_proxy or maybe it's related to the size of the POST data – so still have some further testing to do I think.

Cheers
Aaron



#Reverse Proxy Apache Configuration
NameVirtualHost *:80
ProxyRequests off
<VirtualHost *:80>
   ServerName https://intranet.example.com
   SSLProxyEngine on
   ProxyPass / https://intranet.example.com/
   <Location "/">
       AuthType shibboleth
       ShibRequestSetting requireSession 1
       Require eduPersonAffiliation staff
   </Location>
</VirtualHost>
ProxyPass /Shibboleth-proxy.sso !
<Location /Shibboleth-proxy.sso>
  Satisfy Any
  Allow from all
  AuthType None
  Require all granted
</Location>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120402/49db6d9b/attachment.html