Kann SAMLCredential.getRemoteEntityID() vertrauenswürdig sein?

Question

Ich implementiere Spring SAML in einer App, die mit mehreren Identitätsanbietern konfiguriert ist. Meine IdP-Metadaten-Konfiguration hat mehrere ExtendedMetadataDelegate mit einem HTTPMetadataProvider und Alias ​​für jeden IdP. Die App wählt den zu verwendenden Anbieter aus, indem sie SAMLContextProvider auf ähnliche Weise wie this erweitert.

Wenn ein IdP eine Autorisierung sendet, muss meine App wissen, von welchem ​​IdP sie stammt (verschiedene Anbieter haben unterschiedliche Sicherheitsberechtigungen). Ich mache dies als docs vorschlagen und mit einer benutzerdefinierten SAMLUserDetailsService und die SAMLCredential.getRemoteEntityID() zu bestimmen, welche IdP die Anfrage gemacht.

Meine Frage ist, kann ich mich auf die RemoteEntityID verlassen, um den Anbieter zu identifizieren? Was passiert, wenn ein IdP-Anbieter seine Metadaten aktualisiert, um eine andere Entitäts-ID oder sogar eine "gefälschte" Entitäts-ID aufzunehmen, die mit einem anderen Anbieter identisch ist? Wäre es nicht besser, den von uns definierten Peer-Alias ​​zu verwenden?

Ich bin neu bei SAML, daher ist es sehr wahrscheinlich, dass ich ein grundlegendes Konzept verstehe. Ich möchte nur sicherstellen, dass ich mit dieser Konfiguration kein Sicherheitsloch öffne.

Answer 1

Dies ist eine gute Frage. Ich kannte die Antwort nicht, also probierte ich es aus.

Ich habe in meiner Testumgebung eine Instanz von MS ADFS und SpringSAML Projekt mit einem Service Provider und Identity Provider konfiguriert (für ADFS). In meiner benutzerdefinierten SAMLUserDetailsService verwende ich SAMLCredential.getRemoteEntityID(), um festzustellen, aus welchem ​​IDP die Anfrage stammt.

Ich führte eine erfolgreiche Anmeldung durch, änderte dann den Namen der ADFS EntityID und versuchte dann erneut, mich anzumelden. Dies führte zu einer Nachricht AuthNResponse; SUCCESS; 127.0.0.1 in den Protokollen, aber einem Fehler im Browser. Ich habe es erneut mit Debug aktiviert im UserDetailService und festgestellt, dass die Anfrage irgendwo fehlschlägt, bevor es den UserDetailService erreicht, aber ich sehe keine Fehlermeldungen in den Protokollen.

Um Ihre Frage zu beantworten (und vielleicht jemand anderes kann definitiv antworten), behandelt SpringSAML dieses Szenario entsprechend, indem es ausgibt. Es gibt keine Fehlermeldung in den Protokollen. Ich nehme an, das liegt daran, dass es ein etwas ungewöhnliches Szenario oder nur ein Fehler ist.

Soweit eine Entity-ID eines anderen Identitätsanbieters gefälscht wird, werden die SAML-Anforderungen signiert, und daher muss jeder, der versucht, eine IDP-Nachricht zu schreiben, auch Zugriff auf seinen privaten Schlüssel haben.

Schließlich ist der Alias ​​nicht in der Anfrage, daher kann er nicht zur Unterscheidung zwischen IDPs verwendet werden.