IdP-initiiertes SSO vs. SP-initiiertes SSO#

Terminologie#

• Identity Provider (IdP): Der Dienst, der Benutzeridentitäten speichert und authentifiziert.
• Service Provider (SP): Eine Website oder ein Dienst, der Benutzern Dienstleistungen bereitstellt.
• Single Sign-On (SSO): Ein Sitzungs- und Benutzer-Authentifizierungsdienst, der es einem Benutzer ermöglicht, einen Satz von Anmeldedaten (z. B. Name und Passwort) zu verwenden, um auf mehrere Anwendungen zuzugreifen.
• SAML: Security Assertion Markup Language ist ein offener Standard zum Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Parteien, insbesondere zwischen einem Identity Provider und einem Service Provider. Es ist ein häufig verwendetes Protokoll für SSO. Sobald ein Benutzer erfolgreich vom IdP authentifiziert wird, sendet der IdP eine SAML-Assertion an den SP, den der SP validiert und dem Benutzer Zugang gewährt.
• OIDC: OpenID Connect ist ein moderneres und sichereres Protokoll für SSO. Es basiert auf OAuth 2.0 und bietet eine Möglichkeit zur Überprüfung der Identität des Benutzers basierend auf der vom IdP durchgeführten Authentifizierung. Sobald ein Benutzer erfolgreich vom IdP authentifiziert wird, sendet der IdP ein im JWT-Format formatiertes Token an den SP, das der SP validiert und dem Benutzer Zugang gewährt.

SP-initiiertes SSO#

Wie der Name schon sagt, wird das SP-initiierte SSO vom Service Provider initiiert. Der Benutzer startet den Authentifizierungsprozess, indem er auf eine Ressource auf der Website des SP zugreift. Der SP leitet den Benutzer dann zur Authentifizierung an den IdP weiter. Sobald der Benutzer authentifiziert ist, generiert der IdP ein Token (OIDC) oder eine SAML-Assertion (SAML) und sendet es zurück an den SP. Der SP validiert das Token oder die Assertion und gewährt dem Benutzer Zugang.

1. Der Benutzer besucht die Website des SP und versucht, auf eine Ressource zuzugreifen.
2. Der Benutzer klickt auf den Login-Button des SSO-Anbieters (z. B. Google, Azure AD, Okta, etc.).
3. Der SP leitet den Benutzer zur Authentifizierung an den IdP weiter.
4. Der Benutzer loggt sich beim IdP ein.
5. Der IdP sendet ein Token oder eine Assertion zurück an den SP.
6. Der SP validiert das Token oder die Assertion und gewährt dem Benutzer Zugang.

IdP-initiiertes SSO#

Im Gegensatz zum SP-initiierten SSO wird das IdP-initiierte SSO vom Identity Provider initiiert. Der Benutzer startet den Authentifizierungsprozess von der Website des IdP aus. Normalerweise findet der Benutzer eine Liste unterstützter SP-Anwendungen auf dem Portal des IdP. Der Benutzer klickt auf die SP-Anwendung und wird mit einer vor-autentifizierten Identität zur Website des SP weitergeleitet.

1. Der Benutzer loggt sich beim IdP ein.
2. Der Benutzer besucht das IdP-Portal und wählt eine SP-Anwendung aus.
3. Der IdP validiert die aktuelle Sitzung des Benutzers und leitet den Benutzer mit einer vor-autentifizierten SSO-Identität an den SP weiter.
4. Der SP validiert die SSO-Identität und gewährt dem Benutzer Zugang.

IdP-initiiertes SSO vs. SP-initiiertes SSO#

Vorteile von IdP-initiiertem SSO gegenüber SP-initiiertem SSO#

IdP-initiierter SSO wird häufiger von großen Unternehmen und Organisationen verwendet, die auf verschiedene Drittanbieter-Apps oder -Dienste angewiesen sind, wie Workday, Salesforce usw. Es bietet eine zentrale Möglichkeit zur Verwaltung des Benutzerzugangs zu mehreren Anwendungen und zur Durchsetzung von SSO-Authentifizierungen. Durch die Aktivierung von IdP-initiiertem SSO können Mitarbeiter direkt über das Portal des IdP auf die verbundenen Anwendungen zugreifen, ohne die Website jeder Anwendung besuchen zu müssen, wodurch die Einarbeitungszeit verkürzt und das Benutzererlebnis verbessert wird.

Risiken von IdP-initiiertem SSO gegenüber SP-initiiertem SSO#

IdP-initiierter SSO birgt gegenüber SP-initiiertem SSO mehr Risiken.

1. Fehlender Authentifizierungskontext: Alle vom IdP initiierten Authentifizierungsanforderungen sind unaufgefordert. Somit initiiert der SP den Authentifizierungsprozess, was möglicherweise die Tür für unbefugten Zugriff öffnet. Es besteht das Risiko, dass die Sitzung des Benutzers gekapert werden könnte. Ein bösartiger Akteur könnte den Anmeldeprozess für einen legitimen Benutzer ohne dessen Wissen oder Zustimmung einleiten.

2. Sitzungsfixierung: Da der SP den Authentifizierungsprozess nicht initiiert, könnte die Sitzung des Benutzers auf die Sitzung des IdP festgelegt werden. Dies könnte zu Sitzungsfixierungsangriffen führen, bei denen ein Angreifer die Sitzung des Benutzers mit der Sitzung des IdP verknüpfen und unbefugten Zugang zum Konto des Benutzers erlangen könnte.

3. Phishing-Angriffe: IdP-initiierter SSO könnte anfällig für Phishing-Angriffe sein. Ein bösartiger Akteur könnte den Benutzer dazu verleiten, ein gefälschtes IdP-Portal zu besuchen und seine Anmeldedaten zu stehlen. Sobald sich der Benutzer anmeldet, könnte der Angreifer den Benutzer mit einer vor-autentifizierten Identität an den SP weiterleiten.

4. Keine Sicherstellung der Anforderungsvalidierung: In einem SP-initiierten SSO wird normalerweise das SP die erforderlichen Sicherheitsinformationen in die Anforderung an den IdP aufnehmen, um die Integrität der Anforderung zu gewährleisten. Sobald das SP die Authentifizierungsantwort erhält, wird es diese Informationen validieren, um CSRF-Angriffe zu verhindern. Z.B. der state-Parameter in OIDC und RelayState in SAML. In IdP-initiiertem SSO initiiert der SP jedoch den Authentifizierungsprozess nicht, sodass das SP keine Sicherstellung der Anforderungsvalidierung hat.

Einschränkungen von IdP-initiiertem SSO gegenüber SP-initiiertem SSO#

IdP-initiiertes SSO wird von OIDC aufgrund der oben genannten Schwachstellen nicht unterstützt. OIDC erfordert, dass der SP den Authentifizierungsprozess initiiert, um die Integrität der Anforderung sicherzustellen. Selbst in Fällen, in denen Benutzer den Authentifizierungsprozess von einem Drittanbieter starten, der nicht der SP ist, sollte der Benutzer zuerst an den SP weitergeleitet werden, um den Authentifizierungsprozess zu initiieren.

Aber in SAML ist IdP-initiiertes SSO möglich. Der IdP kann eine SAML-Assertion generieren, ohne dass der SP den Authentifizierungsprozess initiiert. In einem SAML IdP-initiierten SSO könnte eine SAML-Assertion ohne ordnungsgemäßes RequestID und RelayState direkt an die ACS-URL des SP gesendet werden. Der SP sollte in der Lage sein, diese Art von Assertion zu verarbeiten und dem Benutzer Zugang zu gewähren. (Hinweis: Ohne RequestID und RelayState hat der SP keine Sicherstellung der Integrität der Anforderung).

Fazit#

Obwohl IdP-initiiertes SSO eine zentrale Möglichkeit bietet, den Benutzerzugang zu mehreren Anwendungen zu verwalten, birgt es im Vergleich zu SP-initiiertem SSO mehr Risiken. SP-initiiertes SSO ist sicherer und bietet mehr Sicherheiten hinsichtlich der Integrität der Authentifizierungsanforderung. Es wird empfohlen, SP-initiiertes SSO sowohl für OIDC als auch für SAML-basiertes SSO zu verwenden.