Quantcast

Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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>
   SSLProxyEngine on
   <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>


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Peter Schober
* Aaron Roots <[hidden email]> [2012-04-02 08:19]:
> 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.

To complete the loop (Tom S has just set a pointer from there to
here): Here's the start of a related thread, mentioned (but not
referenced) by Scott on this list earlier:
https://www.terena.org/mail-archives/tf-emc2/msg02135.html
-peter
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Cantor, Scott E.
In reply to this post by Aaron Roots
> 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.

I reported that something was being observed by people running gateway-based SAML deployments a couple of weeks ago (though I didn't mention the gateway part, that hadn't been established as the trigger).

The thing that has to be verified is that the IdP is expiring the page that returns the form containing the javascript in each case. If it expires the form, then the browser is clearly at fault, and there's a very serious bug. If it doesn't expire the form, this is Safari being Safari, and it isn't the first time I've seen it do things like this.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Aaron Roots
Hi Scott,

I have done some packet captures and cross checked with the Safari Web
Inspector - and this is what I see in the headers from the IdP

Headers from first /idp/profile/SAML2/Redirect/SSO -> SP (Reverse Proxy)
Date: Tue, 03 Apr 2012 01:23:47 GMT
Transfer-Encoding: Identity
Connection: close
Pragma: no-cache
Content-Type: text/html;charset=UTF-8
Cache-Control: no-cache, no-store
Set-Cookie: _idp_authn_lc_key=#######key1_value#######; Version=1;
Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/idp
Expires: 0


Headers from second /idp/profile/SAML2/Redirect/SSO -> SP (Intranet)

Date: Tue, 03 Apr 2012 01:23:57 GMT
Transfer-Encoding: Identity
Connection: close
Pragma: no-cache
Content-Type: text/html;charset=UTF-8
Cache-Control: no-cache, no-store
Set-Cookie: _idp_authn_lc_key=#######key2_value#######; Version=1;
Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/idp
Expires: 0


I believe that the headers "Cache-Control: no-cache, no-store", "Pragma:
no-cache", or "Expires: 0" are what is needed to expire the page - but
feel I should confirm.



The HTML content served in both forms is correct on the IdP side capture -
Safari web inspector unfortunately does not show the HTML content when
javascript is enabled (when javascript is disabled - Safari web inspector
shows the same content as the IdP - but the process works with javascript
disabled works).

And as I said before - the POST to the SP show the exact same content in
both POSTs (where the second POST should be different)


Cheers
Aaron



On 2/04/12 11:32 PM, "Cantor, Scott" <[hidden email]> wrote:

>> 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.
>
>I reported that something was being observed by people running
>gateway-based SAML deployments a couple of weeks ago (though I didn't
>mention the gateway part, that hadn't been established as the trigger).
>
>The thing that has to be verified is that the IdP is expiring the page
>that returns the form containing the javascript in each case. If it
>expires the form, then the browser is clearly at fault, and there's a
>very serious bug. If it doesn't expire the form, this is Safari being
>Safari, and it isn't the first time I've seen it do things like this.
>
>-- Scott
>
>--
>To unsubscribe from this list send an email to
>[hidden email]

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Cantor, Scott E.
On 4/2/12 10:06 PM, "Aaron Roots" <[hidden email]> wrote:
>
>I believe that the headers "Cache-Control: no-cache, no-store", "Pragma:
>no-cache", or "Expires: 0" are what is needed to expire the page - but
>feel I should confirm.

Yes, there's nothing else it can do.

I don't really understand what you posted in terms of the design here. All
I wonder is, why does this work with two different SPs in a row? I don't
see why that's any different, but the only deployments that seem to see
this bug are ones that are doing things I don't understand very clearly. I
guess it must have something to do with having intervening
request/response pairs between the forms.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Aaron Roots
Cheers for the clarification Scott.

I can understand the confusion on the design - I run into the same
discussions around the office about why we are doing it this way.

Basically it boils down to a business/security requirement - that we are
not allowed to directly expose the intranet server on the internet.
However they also want it available through a VPN or authenticated proxy.
The VPN option would require configuration and support of users' machines
- so we selected the authenticated reverse proxy as the easiest to support
solution that met the requirements.

Then there was of course a choice of Authentication mechanisms that we
could have used on the reverse proxy - and we could have used file-based
or LDAP basic auth. But Shibboleth is so awesome - why would we choose
anything else.

Safari issue aside - the Shibboleth Reverse Proxy process/setup works
really well and is completely unobtrusive for the end user - especially
when compared to the previous solution we had in place (which involved URL
rewriting, fake landing pages, and a process diagram that rivalled the
Shibboleth expert demo:
http://www.switch.ch/aai/demo/2/resources/expert_complete.htm) - best of
all it was that complicated and non-standard that it had many bugs we
could not fix. I would completely recommend the Shibboleth Reverse Proxy
setup to someone facing the same requirements - of course on the hope that
Apple will sort out the Safari issue in the future.

Cheers
Aaron


On 3/04/12 12:30 PM, "Cantor, Scott" <[hidden email]> wrote:

>On 4/2/12 10:06 PM, "Aaron Roots" <[hidden email]> wrote:
>>
>>I believe that the headers "Cache-Control: no-cache, no-store", "Pragma:
>>no-cache", or "Expires: 0" are what is needed to expire the page - but
>>feel I should confirm.
>
>Yes, there's nothing else it can do.
>
>I don't really understand what you posted in terms of the design here. All
>I wonder is, why does this work with two different SPs in a row? I don't
>see why that's any different, but the only deployments that seem to see
>this bug are ones that are doing things I don't understand very clearly. I
>guess it must have something to do with having intervening
>request/response pairs between the forms.
>
>-- Scott
>
>--
>To unsubscribe from this list send an email to
>[hidden email]

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Aaron Roots
In reply to this post by Peter Schober
Apple have released 5.1.7 and after installing I can no longer reproduce
the issue I was experiencing

http://support.apple.com/kb/HT5282

Cheers

Aaron

Just to note: Sarfari 5.1.6 was included in the main OSX 10.7.4 update -
however this still had the issue and the latest Safari was not available
until after installing this update




On 2/04/12 11:17 PM, "Peter Schober" <[hidden email]> wrote:

>* Aaron Roots <[hidden email]> [2012-04-02 08:19]:
>> 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.
>
>To complete the loop (Tom S has just set a pointer from there to
>here): Here's the start of a related thread, mentioned (but not
>referenced) by Scott on this list earlier:
>https://www.terena.org/mail-archives/tf-emc2/msg02135.html
>-peter
>--
>To unsubscribe from this list send an email to
>[hidden email]

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Cantor, Scott E.
On 5/9/12 7:21 PM, "Aaron Roots" <[hidden email]> wrote:

>Apple have released 5.1.7 and after installing I can no longer reproduce
>the issue I was experiencing
>
>http://support.apple.com/kb/HT5282

Thanks for the update. I'm still under the impression that there isn't any
standard Shibboleth behavior that is vulnerable to this bug, but if that's
not the case, please let us know with the security reporting form.

(I know it's not our bug regardless, but if there were something we did
that was vulnerable to it, and we could work around it, it may still be
justifiable.)

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Loading...