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" <cantor.2 at osu.edu> 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
>users-unsubscribe at shibboleth.net