Von SP und IdP initiiertes SSO

In diesem Artikel werden die Konzepte von SP und IdP Initiated SSO zwischen zwei Federation-Deployments erläutert und die Unterschiede zwischen diesen beiden Flows erläutert.

In diesem Artikel wird auch das Konzept eines Benutzerstatus oder einer Rückgabe-URL erläutert, die während des Federation-SSO zwischen IdP und dem SP gemeinsam verwendet wird. Dieses Konzept wird aufgerufen:

RelayState für SAML 2.0 TARGET für SAML 1.1 wctx für WS-Fed 1.1
openid.return_to für OpenID 2.0 (Rückgabe-SSO)
URL kann einen Abfrageparameter enthalten, der den Benutzerstatus am SP darstellt)

In diesem Artikel werden Beispiele mit dem SAML 2.0-Protokoll dargestellt, obwohl dasselbe für die anderen Protokolle gilt.

Federation-SSO-Abläufe

Topologie

Ein typisches Federation-Deployment besteht aus den folgenden Entitys:

Eine Sicherheitsdomain für den IdP-Server, bei der der Benutzer über einen Account verfügt und die Authentifizierung stattfindet
Eine Sicherheitsdomain für den SP-Server mit
- Ein SP Federation-Server
- Ein SSO-Server (manchmal sind der SSO-Server und der SP Federation-Server dieselbe Entity)
- Mit dem SSO-Server integrierte SSO-Web-Agents schützen Ressourcen und stellen sicher, dass der Benutzer authentifiziert und für den Zugriff auf eine Ressource autorisiert ist. Andernfalls kann es zu einem Authentifizierungsablauf oder einem Autorisierungsfehler kommen
- Ressourcen oder Webanwendungen
Beschreibung der Abbildung Federation_deployment_Screen.jpg

Vom Serviceanbieter initiiertes SSO

Ein vom SP initiierter SSO-Ablauf ist ein Federation-SSO-Vorgang, der von der SP-Sicherheitsdomain gestartet wurde, indem der SP-Föderationsserver eine Federation-Authentifizierungsanforderung erstellt und den Benutzer mit der Nachricht und einer kurzen Zeichenfolge, die den Vorgangsstatus darstellt, an IdP umleitet:

Die Federation Authentication Request variiert je nach verwendetem Protokoll:
- BEISPIEL 2.0: AuthnRequest
- SAML 1.1: Eine URL mit einem Parameter, der den SP darstellt
- WS-Fed: eine URL mit einem wtrealm-Parameter, der den SP und andere optionale Parameter darstellt
- OpenID 2.0: OpenID 2.0-Anforderung
Der Vorgangsstatus (den der Benutzer vor dem Start des Federation-SSO-Vorgangs ausgeführt hat) wird in der mit dem Benutzer an IdP gesendeten Nachricht übermittelt, nicht als vollständiger Status, sondern als Zeiger auf den Status im Laufzeitspeicher des SP-Servers. Diese Informationen werden je nach Protokoll unterschiedlich vermittelt:
- SAML 2.0: Parameter RelayState
- SAML 1.1: TARGET-Parameter
- WS-Fed: Parameter wctx
- OpenID 2.0: openid.return_to-Parameter, der eine SP-URL ist, bei der der der Benutzer nach der Authentifizierung bei IdP umgeleitet wird, die zur Laufzeit vom SP generiert wird, und als solcher einen Abfrageparameter enthalten kann, der einen Betriebsstatus referenziert

Hinweis zum Betriebsstatus: Im Allgemeinen sollte der in der Nachricht gemeinsam verwendete Status nicht zu lang sein, da er die Umleitungsflüsse unterbrechen könnte, wobei die Länge der Umleitungs-URL die maximale Länge überschreitet, die Browser für URLs verarbeiten können. Daher ist es beim von SP initiierten SSO immer vorzuziehen, den SP zu haben

Betriebsstatus im Speicher/DB-Speicher am SP speichern
Senden Sie als RelayState/TARGET/wctx einen Zeiger zum Betriebsstatus

Es gibt zwei Möglichkeiten, einen vom SP initiierten SSO-Ablauf auszulösen:

Der Benutzer fordert Zugriff auf eine Ressource an, die einen Federation-SSO-Ablauf startet. Nachdem der Federation-SSO-Vorgang ausgeführt wurde, wird der Benutzer zurück zur angeforderten Ressource umgeleitet.
Oder der Benutzer greift direkt auf einen Service auf dem SP-Server zu, um einen Federation-SSO-Ablauf mit einem Remote-IdP zu starten. In diesem Fall gibt der Benutzer in der Regel die URL an, an die der Benutzer nach der Ausführung des Federation-SSO-Vorgangs umgeleitet werden soll.

Auf Ressourcen zugreifen

Dies ist der häufigste Ablauf für Federation-SSO-Vorgänge, bei denen der Benutzer versucht, auf eine geschützte Ressource zuzugreifen, und das SSO-System zur Laufzeit bestimmt, dass der Benutzer über Federation-SSO authentifiziert werden muss.

Für diesen Ablauf können folgende Anwendungsfälle verwendet werden:

Benutzer klickt auf einen Link auf einer Seite, die auf die geschützte Ressource verweist
Benutzer klickt auf einen Link auf einer Portalseite, die auf die geschützte Ressource verweist
Benutzer hat ein Lesezeichen für die geschützte Ressource

Der Ablauf umfasst die folgenden Schritte:

Benutzerbrowser fordert Zugriff auf eine geschützte Ressource an
Der SSO-Web-Agent fängt den Aufruf ab, bestimmt, dass der Benutzer authentifiziert werden muss, und gibt eine Umleitung zurück an den Browser des Benutzers aus
Der Browser des Benutzers greift auf den SSO-Server zu, der vom SSO-Web-Agent umgeleitet wird
Der SSO-Server bestimmt, dass der Benutzer über das Federation-SSO authentifiziert werden soll, wählt eine IdP aus, erstellt eine SAML 2.0 AuthnRequest-Nachricht, speichert den Betriebsstatus im SSO-Serverspeicher und leitet den Browser des Benutzers an IdP um, wobei die SAML-Nachricht und eine Zeichenfolge den Betriebsstatus beim SP referenziert
Der Browser des Benutzers greift mit der Nachricht AuthnRequest auf den SAML 2.0-Service IdP zu.

Beschreibung der Abbildung Accessing_Resources_Screen.jpg

Nachdem die IdP die SAML 2.0 AuthnRequest-Nachricht empfangen hat, bestimmt der Server, ob der Benutzer erneut herausgefordert werden muss (noch nicht authentifiziert, Session wegen Timeout abgebrochen...). Nach der möglichen Identifizierung des Benutzers wird der Federation-SSO-Ablauf fortgesetzt.

Die IdP erstellt eine SSO-Antwort mit einer SAML 2.0-Assertion, die Benutzerinformationen sowie Authentifizierungsdaten enthält, und leitet den Browser des Benutzers mit der Nachricht und dem Parameter RelayState an den SP um
Der Browser des Benutzers zeigt die SSO-Antwort an den SP-Server an
Der SP validiert die SAML 2.0-Assertion und erstellt eine SSO-Session für den Benutzer. Der SSO-Server leitet dann den Browser des Benutzers zurück zur ursprünglich angeforderten Ressource
Der Browser des Benutzers fordert Zugriff auf die Ressource an. Dieses Mal erteilt der SSO-Web-Agent Zugriff auf die Ressource
Die Webanwendung gibt eine Antwort an den Browser des Benutzers zurück

Beschreibung der Abbildung Accessing_Resources_Response_Screen.jpg

Wie bereits erwähnt, wird dieser Ablauf am häufigsten verwendet, da das Federation-SSO nur zur Laufzeit vom SSO-Server ausgelöst wird, ohne dass andere Komponenten in der SP-Sicherheitsdomain Federation kennen müssen.

Federation-SP-Service aufrufen

Dieser Ablauf wird nicht häufig verwendet, da er impliziert, dass das Federation-SSO beim SP gestartet wird, indem auf einen Service auf dem SP-Server zugegriffen wird, und indem eine vorhandene gültige Session nicht berücksichtigt wird, die der Benutzer bereits haben könnte. Daher sollte dies vermieden werden, da dies Auswirkungen auf die Performance hat auf:

Die Server als Federation-SSO sind teuer (XML für einige Protokolle, digitale Signaturen zum Schutz der Nachrichten, Kommunikation zwischen Servern)
Die Benutzererfahrung als Browser wird über verschiedene Domains hinweg umgeleitet, sodass eine Verzögerung auftritt, bevor der Benutzer auf die gewünschte geschützte Ressource zugreifen kann.

Für diesen Ablauf können folgende Anwendungsfälle verwendet werden:

Benutzer klickt auf einen Link auf einer beliebigen Seite, die auf die geschützte Ressource verweist (ungewöhnlich)
Benutzer klickt auf einen Link auf einer Portalseite, die auf die geschützte Ressource verweist

Die Anwendungsfälle, in denen dieser Ablauf verwendet wird, umfassen die folgenden Schritte:

Der Browser des Benutzers greift auf den SP zu, um einen Federation-SSO-Ablauf zu starten, indem optional angegeben wird
1. Die URL, an die der Browser des Benutzers nach Abschluss des Federation-SSO umgeleitet werden soll
2. Die zu verwendende IdP
Der SSO-Server wählt eine IdP aus (sofern nicht angegeben) und wählt die Standard-Rückgabe-URL aus (sofern nicht angegeben), erstellt eine SAML 2.0 AuthnRequest-Nachricht, speichert den Betriebsstatus im SSO-Serverspeicher und leitet den Browser des Benutzers an IdP um, wobei die SAML-Nachricht und eine Zeichenfolge den Betriebsstatus im SP referenziert
Der Browser des Benutzers greift mit der Nachricht AuthnRequest auf den SAML 2.0-Service IdP zu.

Beschreibung der Abbildung IdP_Service_with_AuthnRequest_Screen.jpg

Die IdP erstellt eine SSO-Antwort mit einer SAML 2.0-Assertion, die Benutzerinformationen sowie Authentifizierungsdaten enthält, und leitet den Browser des Benutzers mit der Nachricht und dem Parameter RelayState an den SP um
Der Browser des Benutzers zeigt die SSO-Antwort an den SP-Server an
Der SP validiert die SAML 2.0-Assertion und erstellt eine SSO-Session für den Benutzer. Der SSO-Server leitet dann den Browser des Benutzers zurück zur ursprünglich angeforderten Ressource
Der Browser des Benutzers fordert Zugriff auf die Ressource an. Dieses Mal erteilt der SSO-Web-Agent Zugriff auf die Ressource
Die Webanwendung gibt eine Antwort an den Browser des Benutzers zurück

Beschreibung der Abbildung IdP_Service_with_Response_Screen.jpg

Dieser Ablauf sollte selten verwendet werden, da das Federation-SSO statisch ausgelöst wird, selbst wenn der Benutzer bereits über eine gültige SSO-Session verfügt. Außerdem bedeutet dies, dass einige Komponenten in der SP-Sicherheitsdomain über den SP-Service informiert sind.

IdP Durch SSO initiiertes

Ein von IdP initiierter SSO-Ablauf ist ein Federation-SSO-Vorgang, der von der IdP-Sicherheitsdomain gestartet wurde, indem der IdP-Föderationsserver eine Federation-SSO-Antwort erstellt und den Benutzer mit der Antwortnachricht und einem optionalen Betriebsstatus an den SP umleitet:

Die Federation-SSO-Antwort variiert je nach verwendetem Protokoll:
- SAML 2.0: SAMLResponse mit Assertion
- SAML 1.1: Antwort mit Assertion
- WS-Fed: Antwort mit Assertion
- OpenID 2.0: OpenID 2.0-Antwort
Der optionale Vorgangsstatus in diesem Ablauf übermittelt die URL, an die der Benutzer umgeleitet werden soll, nachdem das Federation-SSO am SP abgeschlossen ist. Wenn der SP fehlt, muss er bestimmen, wohin der Benutzer umgeleitet werden soll. Diese Informationen werden je nach Protokoll unterschiedlich vermittelt:
- SAML 2.0: Parameter RelayState
- SAML 1.1: Parameter TARGET
- WS-Fed: Parameter wctx OpenID 2.0: Dieses Protokoll unterstützt nicht den von IdP initiierten SSO-Ablauf.

Wie im vorherigen Abschnitt erwähnt, sollte der in der Nachricht gemeinsam verwendete Status nicht zu lang sein, da er die Umleitungsflüsse möglicherweise unterbrechen würde, wobei die Länge der Umleitungs-URL die maximale Länge überschreitet, die Browser für URLs verarbeiten können.

Dieser Ablauf wird häufig verwendet, wenn IdP-Benutzer auf Ressourcen zugreifen müssen, die von einem SP gehostet werden. Er ist jedoch nicht die beste Herangehensweise für das Federation-SSO, da er eine vorhandene gültige Session am SP ignoriert, die der Benutzer bereits haben könnte. Daher sollte dies vermieden werden, da dies Auswirkungen auf die Performance hat auf:

Die Server als Federation-SSO sind teuer (XML für einige Protokolle, digitale Signaturen zum Schutz der Nachrichten, Kommunikation zwischen Servern)
Die Benutzererfahrung als Browser wird über verschiedene Domains hinweg umgeleitet, sodass eine Verzögerung auftritt, bevor der Benutzer auf die gewünschte geschützte Ressource zugreifen kann.

Für diesen Ablauf können folgende Anwendungsfälle verwendet werden:

Der Benutzer klickt auf einen Link auf einer IdP-Portalseite, die auf die geschützte Ressource am SP verweist.

Die Anwendungsfälle, in denen dieser Ablauf verwendet wird, umfassen die folgenden Schritte:

Der Browser des Benutzers greift auf IdP zu, um einen Federation-SSO-Ablauf zu starten, indem er Folgendes angibt
1. Der zu verwendende SP
2. Optional die URL, unter der der Browser des Benutzers nach Abschluss des Federation-SSO umgeleitet werden soll
Nachdem der Benutzer identifiziert wurde, erstellt die IdP eine SSO-Antwort mit einer SAML 2.0-Assertion, die Benutzerinformationen sowie Authentifizierungsdaten enthält, und leitet den Browser des Benutzers mit der Nachricht und dem Parameter RelayState an den SP um
Der Browser des Benutzers zeigt die SSO-Antwort an den SP-Server an
Der SP validiert die SAML 2.0-Assertion und erstellt eine SSO-Session für den Benutzer. Der SSO-Server leitet dann den Browser des Benutzers zurück zur ursprünglich angeforderten Ressource
Der Browser des Benutzers fordert Zugriff auf die Ressource an. Dieses Mal erteilt der SSO-Web-Agent Zugriff auf die Ressource
Die Webanwendung gibt eine Antwort an den Browser des Benutzers zurück

Beschreibung der Abbildung SSO_Response_Screen.jpg

Schlussfolgerung

Wie in den verschiedenen Abläufen zu sehen ist, besteht der beste Ansatz bei einem Federation-Deployment darin, dass das Federation-SSO zur Laufzeit vom SSO-Server ausgelöst wird, wenn dies vom SSO-Server als erforderlich erachtet wird. Die anderen Fälle haben einen statischen Ansatz und üben immer einen Federation-SSO-Ablauf aus, selbst wenn er nicht erforderlich ist (wenn der Benutzer beispielsweise bereits eine gültige Session hat), und wenn unnötige Federation-Vorgänge ausgeführt werden, wirkt sich dies aus:

Performance der Server (CPU-, LDAP-/RDBMS-Interaktionen...)
Die Antwortzeit des Benutzers basierend auf der Zeit, die für die Ausführung eines Federation-SSO-Vorgangs mit den beteiligten Umleitungen benötigt wird.

Weitere Lernressourcen

Sehen Sie sich weitere Übungen unter docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning-Kanal YouTube zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.

Titel und Copyright-Informationen

SP vs IdP Initiated SSO

F60244-01

September 2022