[Shib-Users] ssl offloading on the IdP, endpoint mismatch

[Peter Schober]

I'm testing SSL offloading for 2.1.1 IdPs, to play with the
loadbalancers session affinity (stickyness) based on the appliance
introducing it's own HTTP cookies into the requests, so the
loadbalancer needs to unwrap the SSL itself and talks plain HTTP to
the backend server(s).

I'm running into a very clear error message, but currently can't see
what I could change to make this work:

14:03:20.591 - INFO [Shibboleth-Access:72] -
20081218T130320Z|10.0.2.234|idp.example.org:80|/profile/SAML2/Redirect/SSO|

14:03:20.914 - ERROR
[org.opensaml.common.binding.decoding.BaseSAMLMessageDecoder:204] -
SAML message intended destination endpoint
'https://idp.example.org/idp/profile/SAML2/Redirect/SSO' did not match
the recipient endpoint
'http://idp.example.org/idp/profile/SAML2/Redirect/SSO'

14:03:20.914 - ERROR
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:320]
- Message did not meet security requirements
org.opensaml.xml.security.SecurityException: SAML message intended
destination endpoint did not match recipient endpoint

The samlp:AuthnRequest generated by the SP is fine
(Destination="https://idp.example.org/idp/profile/SAML2/Redirect/SSO"),
metadata only has SSL endpoints listed, the load balancer redirects
all requests from HTTP to HTTPS, Firefox's live headers show that the
authnRequest goes to the correct scheme and port, etc.
Obviously all this won't change a thing with regard to the IdP behind
it, which only sees this coming in though plain HTTP.

The IdP's Tomcat runs behing Apache httpd (via mod_proxy_ajp), which
is listening on http://...:80 only. Apache httpd's virtualization
settings don't seem to make a difference here:
ServerName https://idp.example.org:443
UseCanonicalName On

Any pointers?

Cheers,
-peter

--
peter....@univie.ac.at - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140

[Chad La Joie]

wow, creepy. I was just in the process of looking at crypto offloading
to hardware.

At the moment there is no way to turn this check off (for various
reasons it can not currently be put in as an actual security policy rule
which are the only checks you can explicitly turn off).

One very hackish way that you could use to deal with this, and this is
just off the top of my head, would be to write a servlet filter that
returned modified information for various components of the URL. For
example, you'd make getScheme() return 'https' instead of 'http'. I'm
afraid I don't know Apache well enough to know if you can do any similar
magic there.

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch

[Scott Cantor]

> > The IdP's Tomcat runs behing Apache httpd (via mod_proxy_ajp), which
> > is listening on http://...:80 only. Apache httpd's virtualization
> > settings don't seem to make a difference here:

Tomcat has its own, but I don't recall if they apply to the AJP connector. It should be getting that information from Apache, so if Apache isn't passing them along properly, that's a bug.

-- Scott

[Peter Schober]

* Scott Cantor <cant...@osu.edu> [2008-12-18 16:31]:

Thanks, I'll try to look into this,

[Peter Schober]

* Scott Cantor <cant...@osu.edu> [2008-12-18 16:31]:

Thanks, setting this in Tomcat's AJP connector works just fine
(adding proxyPort and scheme), e.g.

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443"
proxyPort="443" scheme="https"
address="127.0.0.1" tomcatAuthentication="false" />

Since all requests ending up here will be directed to https://...:443
this won't be a problem (otherwise several Connectors could be
defined, I guess).