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" <cantor.2 at osu.edu> wrote:

>On 4/2/12 10:06 PM, "Aaron Roots" <aaron.roots at deakin.edu.au> 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
>users-unsubscribe at shibboleth.net