[Shib-Users] Shibboleth 2 with SSL offloading with Big IP F5

[Paul G. Szabady]

Greetings,

I'm new to Shibboleth and have been banging my head against the wall for
a few days now, so I'm hoping someone out there might be able to help.

If I set the "URL Prefix" at the IdP to
http://devsite.unc.edu/Shibboleth.sso, then I can access my application
fine by going to either http or https and things seem to work as
expected *EXCEPT* that after I authenticate, I get returned to
http://devsite-dev.unc.edu. Obviously, this defeats the use of SSL.
Oddly enough, if I then change the url in my browser to
https://devsite-dev.unc.edu I can connect to my application over an
encrypted connection.

When I change my "URL Prefix" to
https://devsite-dev.unc.edu/Shibboleth.sso, I get the following error,
whether I go to http://devsite-dev.unc.edu OR https://devsite-dev.unc.edu.

2009-02-28 20:45:05 ERROR OpenSAML.MessageDecoder.SAML2POST [17]: POST
targeted at (https://devsite.unc.edu/Shibboleth.sso/SAML2/POST), but
delivered to (http://devsite.unc.edu/Shibboleth.sso/SAML2/POST)

I found the following at
https://spaces.internet2.edu/display/SHIB2/NativeSPTroubleshootingCommonErrors,

SAML message delivered with POST to incorrect server URL.

When a SAML message is addressed to a location inconsistent with where
the SP believes it's running, this error will be thrown. The SP pulls
much of this information from the web environment.

1. Verify that the server name and port are properly set in
accordance with the SP's metadata.
2. Rewriting rules in effect for the Shibboleth.sso handler path
must be consistent with the SP's metadata.
3. The IdP needs to properly address the SAML response.

I am fairly certain I have numbers 1 & 2 correct. Can someone tell me
what I need to look for to confirm #3?

Thanks!

--
Paul G. Szabady
Web Systems Manager
ITS Communications
University of North Carolina at Chapel Hill
919.966.5862

[Scott Cantor]

> If I set the "URL Prefix" at the IdP to
> http://devsite.unc.edu/Shibboleth.sso, then I can access my application

I don't know what you mean by URL Prefix, but that's an SP handler base, not
anything to do with the IdP.

> When I change my "URL Prefix" to
> https://devsite-dev.unc.edu/Shibboleth.sso, I get the following error,
> whether I go to http://devsite-dev.unc.edu OR https://devsite-dev.unc.edu.

That means your web site is misconfigured and is not set up properly. It's
not a Shibboleth issue, it's a web site issue. The list archive is full of
threads about it, searching for SSL offloading would probably work.

> 1. Verify that the server name and port are properly set in
> accordance with the SP's metadata.

Add scheme to that list. Your web server believes its virtual host is not
using SSL, but in fact it is (via the offloader). You need to tell it that
https is in use in the Apache configuration. You also need to virtualize the
port to 443 since the physical port is probably 80.

If you get Apache to give you a 404 error page, you'll see it report its
server name and port, etc. If that doesn't show what you expect it to, your
web site is broken.

-- Scott

[Mike Jennings]

If you are using a ssl offloader and the self-referential url's are not
correct then you can do the following to fix this.

If you are using Apache 2.2 (I have done this)

Add https:// to the servername directive. This will allow for the
scheme to be forced to https for the virtual host. The documentation
for this is here:

http://httpd.apache.org/docs/2.2/mod/core.html#servername

This fixed our issue.

Mike Jennings
UNC-CH

[Paul G. Szabady]

Just closing the loop...

A co-worker found the following and it resolved my issue. This appears
to be new in v2.2 as the 2.0 documentation doesn't show this option.

Snippet from http://httpd.apache.org/docs/2.2/mod/core.html#servername:
<snippet>
Sometimes, the server runs behind a device that processes SSL, such as a
reverse proxy, load balancer or SSL offload appliance. When this is the
case, specify the https:// scheme and the port number to which the
clients connect in the ServerName directive to make sure that the server
generates the correct self-referential URLs.
</snippet>

In summary, all I had to do was change my "ServerName" entry
FROM: devsite-dev.unc.edu
TO: https://devsite-dev.unc.edu
and it works.

--
Paul G. Szabady
Web Systems Manager
ITS Communications
University of North Carolina at Chapel Hill
919.966.5862