OpenID Connect

OpenID Connect ist ein einfaches Identitätsprotokoll und ein offener, auf dem Protokoll OAuth 2.0 basierender Standard, der Clientanwendungen ermöglicht, sich auf eine Authentifizierung zu stützen, die von einem OpenID Connect-Provider zur Prüfung einer Benutzeridentität durchgeführt wird.

OpenID Connect verwendet OAuth 2.0 zur Authentifizierung und Berechtigung und erstellt dann Identitäten, die Benutzer eindeutig identifizieren. Clientanwendungen können auch grundlegende Informationen zum Profil eines Benutzers mit einem kompatiblen und REST-konformen Verfahren von OpenID Connect-Providern abrufen.

WebSphere Application Server Liberty unterstützt OpenID Connect 1.0 und fungiert als Client bzw. Relying Party und als Provider beim Web-SSO. Die folgende OpenID Connect-Spezifikation wird unterstützt:

OpenID Connect Core 1.0:
Liberty-Server, die als OpenID Connect-Relying-Partys konfiguriert sind, verwenden den Berechtigungscodeablauf, um die Authentifizierung zu unterstützen.
Als OpenID Connect-Provider konfigurierte Liberty-Server verwenden den Berechtigungscodeablauf und den impliziten Ablauf, um die Authentifizierung zu unterstützen.

Benutzer, die einen Liberty-Server als webbasierte Relying Party verwenden, finden in der Veröffentlichung OpenID Connect Basic Client Implementer's Guide 1.0 einen Teil der Spezifikation OpenID Connect Core, der leichter zu lesen ist und Detailangaben für webbasierte Relying Partys bietet, die den Berechtigungscodeablauf verwenden.

Zugriffstoken
Ein Berechtigungsnachweis, der für den Zugriff auf geschützte Ressourcen verwendet wird. Ein Zugriffstoken ist eine Zeichenfolge, die eine an den Client ausgegebene Berechtigung darstellt.
Berechtigungsendpunkt
Eine Ressource auf einem OpenID-Provider, die eine Berechtigungsanforderung von einem Client akzeptiert, um die Authentifizierung und Berechtigung eines Benutzers durchzuführen. Im Berechtigungscodeablauf gibt der Berechtigungsendpunkt einen Berechtigungsgrant oder -code an den Client zurück. Im impliziten Ablauf gibt der Berechtigungsendpunkt ein ID-Token und ein Zugriffstoken an den Client zurück.
Berechtigungsgrant
Ein Berechtigungsnachweis, der die Zugriffsberechtigung eines Benutzers für Ressourcen darstellt und von einem Client verwendet wird, um ein Zugriffstoken abzurufen.
Anspruch
Bestätigte Informationen über eine Entität, z. B. Telefonnummer, Vorname, Nachname usw.
ID-Token
Ein JSON Web Token (JWT), das Ansprüche zum authentifizierten Benutzer enthält.
Introspektionsendpunkt
Eine Ressource auf einem OpenID-Provider, die einem Client mit einem Zugriffstoken ermöglicht, zur Erstellung des Zugriffstokens verwendeten Informationen, z. B. den Benutzernamen, die Client-ID, bewilligte Gültigkeitsbereiche oder andere Angaben abzurufen.
OpenID Connect-Provider (OP)
Ein OAuth 2.0-Berechtigungsserver, der einem Client oder einer Relying Party Ansprüche bereitstellen kann.
Aktualisierungstoken
Wird vom OP an den Client ausgegeben und verwendet, um ein neues Zugriffstoken abzurufen, wenn das aktuelle Zugriffstoken abläuft, oder um weitere Zugriffstoken abzurufen.
Relying Party (RP)
Ein als OpenID Connect-Client konfigurierter Liberty-Server oder eine Clientanwendung, die Ansprüche von einem OpenID-Provider (OP) abruft.
Geltungsbereich
Eine Berechtigung oder Genehmigung, die den Zugriff auf Ressourcen eines Dritten ermöglicht.
Tokenendpunkt
Eine Ressource auf einem OP, die einen Berechtigungsgrant oder -code von einem Client akzeptiert und dafür ein Zugriffstoken, ein ID-Token und ein Aktualisierungstoken zurückgibt.

Liberty-Server als OpenID Connect-Client

Sie können WebSphere Application Server Liberty als OpenID Connect-Client konfigurieren. Diese Konfiguration ermöglicht dem Liberty-Server, einen anderen Liberty-Server, der als OP für Benutzerauthentifizierung und -berechtigung fungiert, als vertrauenswürdig zu behandeln.

Ein Liberty-Server, der als OpenID Connect-Client konfiguriert ist, unterstützt den Berechtigungscodeablauf des Standards OpenID Connect 1.0.

Im Berechtigungscodeablauf wird jeder Tokenaustausch über den Tokenendpunkt des OpenID Connect-Providers abgewickelt. Zuerst übergibt der Client eine Berechtigungsanforderung an den Berechtigungsendpunkt des OP. Nach erfolgreicher Authentifizierung und Berechtigung beim OP erhält der Client vom OP einen Berechtigungsgrant oder -code. Dieser Berechtigungscode kann dann in einer Anforderung an den Tokenendpunkt des OP gesendet werden. Der Client empfängt ein ID-Token, ein Zugriffstoken und ein Aktualisierungstoken in der Antwort vom Tokenendpunkt. Dann validiert der Client das ID-Token und ruft die Subjekt-ID des Benutzers ab. Dieser profilbasierte Ablauf ist für Clients vorgesehen, die einen geheimen Clientschlüssel zwischen sich und dem OP sicher verwalten können. Außerdem ermöglicht dieser Ablauf Clients auch, ein Aktualisierungstoken abzurufen.

Informationen zur Konfiguration eines Liberty-Servers als OpenID Connect-Client finden Sie unter OpenID Connect-Client in Libety konfigurieren.

Liberty-Server als OpenID Connect-Provider

Sie können WebSphere Application Server Liberty als OpenID Connect-Provider konfigurieren. Diese Konfiguration ermöglicht dem Liberty-Server, als Berechtigungsserver zu fungieren, der von OpenID Connect-Clients verwendet werden kann.

Ein Liberty-Server, der als OpenID Connect-Provider konfiguriert ist, unterstützt den Berechtigungscodeablauf und den impliziten Ablauf des Standards OpenID Connect 1.0. Jeder Ablauf legt fest, wie das ID-Token, das Zugriffstoken und das Aktualisierungstoken an den Client zurückgegeben werden.

Im Berechtigungscodeablauf wird jeder Tokenaustausch über den Tokenendpunkt des OpenID Connect-Providers abgewickelt. Ein OpenID Connect-Provider akzeptiert eine Berechtigungsanforderung von einem Client am Berechtigungsendpunkt des OP. Wenn eine Authentifizierung notwendig ist, führt der OpenID Connect-Provider die entsprechende Authentifizierung durch. Der OpenID Connect-Provider ruft auch alle erforderlichen Zustimmungen oder Berechtigungen vom Benutzer ab, indem er beispielsweise den Benutzer in einem Browser auffordert, den Zugriff auf bestimmte Gültigkeitsbereiche zuzulassen. Wenn die Authentifizierung erfolgreich verlaufen ist oder gar nicht erforderlich war, sendet der OpenID-Provider einen Berechtigungsgrant oder -code an den Client zurück. Der OpenID Connect-Provider akzeptiert dann eine Anforderung, die von dem Client, der den Berechtigungscode enthält, an seinen Tokenendpunkt übergeben wird. Die Anforderung, die den Berechtigungscode einschließt, wird vom OpenID-Provider geprüft. Nach erfolgreicher Validierung gibt der OpenID Connect-Provider eine Antwort an den Client zurück, der ein ID-Token und ein Zugriffstoken enthält.

Im impliziten Ablauf werden im Gegensatz zum Berechtigungscodeablauf alle Token vom Berechtigungsendpunkt zurückgegeben. Der Tokenendpunkt des OP wird nicht verwendet. Zuerst bereitet ein Client eine Berechtigungsanforderung vor und sendet sie an den Berechtigungsendpunkt des OP. Der OpenID Connect-Provider führt dann alle notwendigen Authentifizierungsvorgänge aus und ruft alle erforderlichen Zustimmungen oder Berechtigungen vom Benutzer ab. Der OpenID Connect-Provider fordert den Benutzer beispielsweise in einem Browser auf, den Zugriff auf bestimmte Gültigkeitsbereiche zuzulassen. Nach erfolgreicher Authentifizierung und Berechtigung sendet der OpenID Connect-Provider ein ID-Token und ein Zugriffstoken an den Client zurück. Der Client prüft dann das ID-Token und ruft die Subjekt-ID des Benutzers ab. Dieser Profilablauf ist für Clients vorgesehen, die nicht in der Lage sind, einen geheimen Clientschlüssel zwischen sich und dem OP sicher zu verwalten, z. B. native Anwendungen.

Informationen zur Konfiguration eines Liberty-Servers als OpenID Connect-Provider finden Sie unter OpenID Connect-Provider in Liberty konfigurieren.

Berechtigungscodeablauf

Ein typischer Berechtigungscodeablauf unter Verwendung von OpenID Connect lässt sich wie folgt beschreiben:

  1. Ein Benutzer greift auf eine Anwendung der Relying Party zu.
  2. Die RP bereitet eine Authentifizierungsanforderung vor und leitet den Benutzer an den OP um.
  3. Der OP authentifiziert den Benutzer, beispielsweise indem er ihn zur Eingabe der Berechtigungsnachweise auffordert. Der Benutzer berechtigt die RP, auf die für die Anwendung erforderlichen Informationen zuzugreifen. Der OP generiert einen einmalig verwendbaren Berechtigungscode für die Relying Party.
  4. Der OP leitet den Benutzer wieder zu der Relying Party mit dem Berechtigungscode um.
  5. Die Relying Party ruft den Tokenendpunkt des OP auf, um den Berechtigungscode gegen ein Zugriffstoken, ein ID-Token und ein Aktualisierungstoken auszutauschen.
  6. Die Relying Party verwendet das ID-Token, um den Benutzer zu berechtigen.
Die Abbildung zeigt den grundlegenden Ablauf mit dem OpenID Connect-Clientprofil.

Impliziter Ablauf

Der implizite Ablauf wird nur von Liberty-Servern unterstützt, die als OpenID Connect-Provider agieren. Ein typischer impliziter Ablauf unter Verwendung von OpenID Connect lässt sich wie folgt beschreiben:

  1. Ein Benutzer greift auf eine Anwendung der Relying Party zu.
  2. Die Relying Party bereitet eine Authentifizierungsanforderung vor und leitet den Benutzer an den OP um.
  3. Der OP authentifiziert den Benutzer, beispielsweise indem er ihn zur Eingabe der Berechtigungsnachweise auffordert. Der Benutzer berechtigt die Relying Party für den Zugriff auf die von der Anwendung benötigten Informationen.
  4. Der OP leitet den Benutzer wieder zur Relying Party mit einem ID-Token und einem Zugriffstoken um.
  5. Die Relying Party verwendet das ID-Token, um den Benutzer zu berechtigen.
Die Abbildung zeigt den impliziten Ablauf mit dem OpenID Connect-Clientprofil.

Symbol das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 01.12.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_openid_connect
Dateiname: cwlp_openid_connect.html