Log in problems using proxies

[brucellino]

Several folks have reported this issue

opensaml::FatalProfileException
The system encountered an error 
To report this problem, please contact the site administrator 
Please include the following message in any email:
opensaml::FatalProfileException at (https://discourse.sci-gaia.eu/Shibboleth.sso/SAML2/POST)
Your client's current address (ip.addy.withheld.ok) differs from the one used when you authenticated to your identity provider. To correct this problem, you may need to bypass a proxy server. Please contact your local support staff or help desk for assistance.

This has happened to @BjornPehrson_47a0 and others from SWAMID, then some others from CESNET and now to people from GRNET. @MarcoFargetta_0c9b1 it seems like this issue was never resolved, but we need to take a look. I'm assured that these idps are working for other sps in edugain. Are we doing some wierd filtering in our config ?

[brucellino]

Having discussed this with @MarcoFargetta_0c9b1, it seems that there is no obvious issue with the SP configuration, so we first thought that this was clearly an issue on the client side - which however seemed wierd because we know that the SPs which are giving this issue are definitely working on other IdPs.

However, Kostas gave us a suggestion that the issue may be with a dual IP stack which is confusing Shibboleth. Indeed the SP only has an IPv4 address, whilst the IdP and the client seem to have dual stack enabled - so perhaps the IPv6 address which is reported by the IdP is confusing the SP in some way.

[brucellino]

So, Lukas Hämmerle from SWITCH/edugain managed to solve this problem for us. The filter that was failing was related to a consistency check and in Shibboleth sessions

• checkAddress(boolean) (default is false)

  The IdP will place the IP address of the user agent it authenticated into the assertions it issues. When true, the SP will check this address against the address of the client presenting an assertion before creating a session. While useful for security, NAT and proxy usage (as well as IPv6 support on only either the webserver hosting the IdP or the SP) often make this setting a source of errors.

• consistentAddress(boolean) (default is true)

  When true, the SP will remember the IP address used when creating a session and ensure that all subsequent access associated with this session come from the same address. This can help protect against cookie theft and is less likely than the checkAddress setting to block legitimate access.

We changed the checkAddress boolean to false :

    <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
                  checkAddress="false" handlerSSL="true" cookieProps="https">

It now works for @KostasKoumantaros_e3 where it didn't before...