Security considerations on consistentAddress up to date?

Nate Klingenstein ndk at
Wed Jan 20 11:32:19 UTC 2021


I'm not aware of any other form of binding of the SAML assertion, which is typically a bearer token, to the client, beyond IP addresses.  That makes it prone to being stolen and played by third parties.  consistentAddress is the closest thing we have to protection in widespread implementation that is really feasible, as it at least ensures that subsequent access using the same Shibboleth session comes from the same IP address -- but that's what's breaking things for you here.  (checkAddress is the same idea, but more strict, so that the client has to have the same IP at both the IdP and the SP).  So, this is the best setting available in a general Shibboleth environment for binding the assertion and resulting session to the client.

In theory, there is a number of other ways you could bind the SAML assertion to the client in a more elegant way.  The SAML Holder-of-Key Profile is probably the best, but it also involves the most work and modification to the client and the SP [1].  This links the assertion to the client through asymmetric cryptography, and preferably extended to any ensuing cookie-based sessions, which is a very strong binding, but it is fairly intrusive in its implementation and deployment requirements.  We thought about channel bindings more generally as well [2]..  I don't know how much, if any, of this ever found its way into the Shibboleth code base or extensions.

I'd say all the security considerations are definitely still relevant, and possibly more so today than ever before, unless you trust today's CA's more than you trusted those of previous generations.  That's a judgment call and I think most people would say they have lapsed over time.

So, you're left with the alternatives of moving to one of the more secure channel/assertion bindings and really securing the assertion to the client, which may involve substantial development work, or turning off consistentAddress, which would decrease the security of the SP to client interactions meaningfully [3].


Ready to get posterized by Scott,

Signet, Inc.
The Art of Access ®

-----Original message-----
From: Marco Lechner
Sent: Wednesday, January 20 2021, 1:04 am
To: users at
Subject: Security considerations on consistentAddress up to date?


we do have problems with one important customer facing invalidation of Shibboleth sessions all the time. It pointed out that it might be a similar problem like already being discussed on this list in 2013 [1]. Are the security considerations
 about setting consistentAddress=“false“ still up to date? Or have there been any new aspects, improvements since mobile devices (that might change their IP/Provider quite often) became more significant?

Best reghards

Marco Lechner



i.A. Dr. Marco Lechner

Leiter Fachgebiet RN 1 │ Head RN 1

Bundesamt für Strahlenschutz │ Federal Office for Radiation Protection

Koordination Notfallschutzsysteme │ Coordination Emergency Systems │ RN 1

Rosastr. 9

D-79098 Freiburg

Tel.: +49 30 18333-6724

mlechner at <mailto:mlechner at> <>

Abonnieren Sie den BfS-Newsletter
„StrahlenschutzAktuell“ <>

Folgen Sie uns auf 
Twitter <>

Informationen zum Datenschutz gemäß Artikel 13 DSGVO finden Sie unter: <>


Hinweis zu Anhängen die auf .p7m/.p7c/.p7s oder .asc/.asc.sig enden:

Die .p7?- und .asc-Dateien sind ungefährliche Signaturdateien (digitale Unterschriften). In E-Mail-Clients mit S/MIME Konfiguration (.p7?) oder PGP-Erweiterung (.asc) dienen sie zur:

- Überprüfung des Absenders

- Überprüfung einer evtl. Veränderung des Inhalts während der Übermittlung über das Internet

Die Signaturdateien können ebenso dazu verwendet werden dem Absender dieser Signatur eine E-Mail mit verschlüsseltem Inhalt zu senden. In E-Mail-Clients ohne S/MIME Konfiguration oder PGP-Erweiterung erscheinen die Dateien als Anhang und können ignoriert werden.


For Consortium Member technical support, see

To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list