AddressChecking

It's relatively common to run into problems with client IP address mismatches, either at the time of login or less commonly after a session exists, causing it to be invalidated. The former is very noticeable to the end user, while the latter can be quite random and only gets logged by the web server module (generally in syslog or the Event Log), and not in the shibd.log traces.

There are two settings defined in the <Sessions> element that impact this issue. Both default internally to “true”, though the shipping default for checkAddress is overridden to false now.

checkAddress

This setting controls a comparison that takes place when processing the SAML response message from the IdP and when true, requires that the IP address of the client placed into the initial SAML assertion created by the IdP and the address of the client that delivers the SAML assertion to the SP are the same.

When systems are operating correctly, this mismatch normally occurs because a user's client is behind a proxy, VPN, or some other network translation device that is configured to route traffic such that the address seen by the two web servers aren't the same. This is usually called "split tunnelling" and occurs when only a subset of traffic is routed through the device.

The only way to fix an error like this is to change that networking configuration (which may be impossible) or to change the setting to false.

The security implications of not performing this check are not hugely significant, but the check does strengthen the protocol by limiting the ability of an attacker to steal the assertion in transit and assume the role of the end user by playing the message themselves.

consistentAddress

A separate setting is used after a session is established and causes the system to associate the session with the client's address such that a change to that address will invalidate the session.

This setting ensures that once a session cookie is issued to a client, any further use of that session cookie must be from a client with the same network address. This raises the bar for session hijackers to the level of network address spoofing, which may or may not be simple to do, but is definitely harder than stealing cookies and relies on a different set of attacking skills.

Disabling this setting is much more questionable for the security of a system, and should be much more rarely required unless clients are making use of seriously broken networks.

V3.1+ also includes an additional setting in the <SessionCache> element called unreliableNetworks. This setting can be used to "relax" the address checks when both operands of the comparison match a specied network range, and may allow the consistentAddress setting to stay enabled in some cases.