Sie können einen Liberty-Server als OAuth 2.0-Server für geschützte Ressourcen konfigurieren.
Informationen zu diesem Vorgang
Sie können einen Liberty-Server als OAuth 2.0-Server für geschützte Ressourcen konfigurieren, indem Sie das Feature
openidConnectClient-1.0 in Liberty aktivieren und
inboundPropagation="required" zusätzlich zu anderen Konfigurationsinformationen definieren. Die Konfiguration
für den OAuth 2.0-Ressourcenserver gleicht der im Abschnitt OpenID Connect-Client in Libety konfigurieren beschriebenen.
Jede Partei, die ein OAuth-Bearer-Token (access_token) besitzt, kann dieses Token verwenden, um auf die zugeordneten Ressourcen in Liberty
zuzugreifen.
Der Liberty-Server validiert das Zugriffstoken (access_token) über Fernzugriff beim OAuth-Berechtigungsserver oder direkt beim OpenID Connect-Provider, indem
der OAuth 2.0 Token Introspection-Endpunkt oder
der OpenID Connect-Userinfo-Endpunkt aufgerufen wird.
Vorgehensweise
- Fügen Sie das Liberty-Feature openidConnectClient-1.0 und alle weiteren benötigten Features zur
Datei server.xml hinzu.
Das Feature ssl-1.0 ist auch für das Feature openidConnectClient-1.0 erforderlich. Fügen Sie die folgende Elementdeklaration
im Element featureManager Ihrer Datei server.xml hinzu:
<feature>openidConnectClient-1.0</feature>
<feature>ssl-1.0</feature>
- Konfigurieren Sie ein openidConnectClient-Element und aktivieren Sie dieses Element als OAuth
2.0-Server für geschützte Ressourcen, indem Sie inboundPropagation=”required” hinzufügen. Im Folgenden sehen Sie ein Beispiel
für eine Minimalkonfiguration, die mit dem OpenID Connect-Provider des Liberty-Server und mit dem OAuth 2.0-Berechtigungsserver funktioniert.
<openidConnectClient id="RS" inboundPropagation="required"
clientId="client01"
clientSecret="{xor}LDo8LTor"
validationEndpointUrl="https://server.example.com:443/oidc/endpoint/OP/introspect">
</openidConnectClient>
Anmerkung: In dieser Beispielkonfiguration führt Liberty die OAuth 2.0-Tokenintrospektion durch Festlegung von
validationMethod="introspect" durch. Aus dem vom Introspektionsendpunkt zurückgegebenen
JSON-Objekt wird direkt ein authentifiziertes Subjekt erstellt, ohne dass eine Benutzerregistry erforderlich ist.
Anmerkung: Damit Liberty die Tokenintrospektion durchführen kann, muss der Liberty-OAuth-2.0-Ressourcenserver sich
selbst als OAuth-Client beim OAuth-Berechtigungsserver oder beim OpenID Connect-Provider registrieren und kann dann eine Tokenintrospektinsanforderung ausführen.
Die clientId- und clientSecret-Werte werden vom Berechtigungsserver bereitgestellt.
- Konfigurieren Sie den Truststore des Servers so, dass die Unterzeichnerzertifikate des Berechtigungsservers eingeschlossen werden, und ändern Sie die SSL-Konfiguration des Servers so, dass der konfigurierte Truststore verwendet wird.
Informationen zu Keystores finden Sie unter "SSL-Kommunikation in Liberty aktivieren".
Informationen zu Keystores finden Sie unter SSL-Kommunikation in Liberty aktivieren.
- Optional: Konfigurieren Sie eine Benutzerregistry.
Die vom Berechtigungsserver zurückgegebene Benutzeridentität ist standardmäßig keinem Registry-Benutzer zugeordnet. Deshalb
ist kein Benutzer in der Benutzerregistry erforderlich. Wenn jedoch das Attribut mapIdentityToRegistryUser des
Elements openidConnectClient auf true gesetzt ist, muss es
für die Identität, die vom Berechtigungsserver zurückgegeben wird, einen Benutzereintrag geben, damit die Authentifizierung und Autorisierung
funktionieren.
Weitere Informationen zum Konfigurieren einer Benutzerregistry finden Sie unter Benutzerregistry in Liberty konfigurieren.
- Optional: Konfigurieren Sie Authentifizierungsfilter.
Wenn das Feature
openidConnectClient-1.0 aktiviert und das Element openidConnectClient nicht mit einem Attribut
authFilterRef konfiguriert ist, werden alle nicht authentifizierten Anforderungsversuche mit diesem Element openidConnectClient authentifiziert.
Weitere Informationen zum Konfigurieren des Authentifizierungsfilters finden Sie unter Authentifizierungsfilter.
- Optional: Sie können Liberty als OAuth 2.0-Ressourcenserver für die Zusammenarbeit mit mehreren
Berechtigungsservern und OpenID Connect-Providern konfigurieren, indem Sie mehrere openidConnectClient-Elemente und mehrere Authentifizierungsfilter erstellen.
Jedes openidConnectClient-Element
definiert eine
Vertrauensbeziehung mit einem Berechtigungsserver oder OpenID Connect-Provider und verwendet das Attribut authFilterRef, um auf einen Authentifizierungfilter zu verweisen.
- Optional: Sie können den Liberty-Ressourcenserver so konfigurieren, dass Token validiert und Benutzerdaten vom
OpenID Connect-userinfo-Endpunkt empfangen werden, indem validationMethod="userinfo" definiert wird.
- Optional: Der Liberty-Ressourcenserver verwendet JSON-Ansprüche, die vom Berechtigungsserver stammen, um ein Authentifizierungssubjekt zu erstellen, und Sie können
Regeln für die Zuordnung der JSON zum Subjekt definieren. Weitere Informationen hierzu finden Sie in den Beschreibungen von
userIdentifier, groupIdentifier,
UserUniqueIdentifier, realmIdentifier und
realmName im Abschnitt OpenID Connect-Client.
- Optional: Ein mit Liberty OAuth 2.0 geschützter Ressourcenserver erwartet, dass jede Anforderung ein gültiges
Zugriffstoken enthält, und verwendet keine SSO-Cookies für die Authentifizierung. Es ist jedoch möglich,
Liberty mit authnSessionDisabled="false" so zu konfigurieren, dass ein SSO-Cookie erstellt wird.
- Optional: Sie können die SPI
com.ibm.wsspi.security.oauth.UserCredentialResolver implementieren, um eine
JSON über das Programm einem Subjekt zuzuordnen.
Ergebnisse
Sie haben die Mindestkonfiguration definiert, die erforderlich ist, um einen Liberty-Server als einen mit
OAuth 2.0 geschützten Ressourcenserver zu konfigurieren, der in der Lage ist, mit einem OAuth-Berchtigungsserver oder einem OpenID Connect-Provider zu kommunizieren.