OpenID-Provider für OAuth-Anforderungen mit zwei Beteiligten konfigurieren

Beim typischen OAuth-Datenfluss gibt es drei "Beteiligte" oder Phasen der Interaktion zwischen einem Client und einem Berechtigungsserver. Bei OAuth-Szenarien mit zwei Beteiligten verwendet der Client vorab autorisierte Bereiche, sodass keine Interaktion mit dem Benutzer erforderlich ist und einer der Beteiligten bzw. eine der Interaktionsphasen des typischen Datenflusses entfällt. Konkret bedeutet dies, dass der Benutzer sich nicht gegenüber dem Berechtigungsserver authentifizieren muss und keine Zustimmung zur gemeinsamen Nutzung der von den angeforderten Bereichen angegebenen Informationen geben muss. Stattdessen werden alle angeforderten Bereichsparameter als vorab autorisiert betrachtet und dem Anforderungstoken automatisch hinzugefügt, das dann an den Berechtigungsserver gesendet wird.

Vorbereitende Schritte

Bei dieser Task wird davon ausgegangen, dass Ihr Liberty-Server ordnungsgemäß mit einem OpenID Connect-Provider konfiguriert ist.

Informationen zu diesem Vorgang

Bei Szenarien mit zwei Beteiligten oder Phasen kann ein OpenID Connect-Client eine HTTP-Anforderung mit zwei Beteiligten mit dem Grant-Typ (grant type) client_credential oder resource owner password senden. Diese Anforderungen passieren nicht den Berechtigungsendpunkt, sodass es keine Einwilligungserklärung für Bereiche gibt, in denen Benutzer den angeforderten Bereichen zustimmen. Der OpenID Connect-Provider muss aber dennoch die autorisierten Bereiche in seinem access_token-Inhalt bearbeiten.

Als OpenID Connect-Provider konfigurierte Liberty-Server, die für die Bearbeitung von OAuth-Anforderungen mit zwei Beteiligten ausgestattet sind, genehmigen die vorab autorisierten Bereiche unter Verwendung der folgenden Kriterien:

  1. Wenn der Parameter grant_type einer Anforderung den Wert client_credential oder resource owner password hat und die Anforderung eine OAuth 2.0-Anforderung ist, werden alle in der Anforderung definierten Bereiche genehmigt und in den Inhalt des Zugriffstokens kopiert. Dies ist das bestehende Verhalten des OAuth 2.0-Features.
  2. Wenn die Anforderung eine OpenID Connect- oder JWT-Token-OAuth-Anforderung ist, werden die folgenden Kriterien verwendet:
    • Wenn in der Anforderung kein Bereichsparameter angegeben ist, akzeptiert der OpenID Connect-Provider die Anforderung nicht.
    • Die angeforderten Bereiche müssen in der Liste der Bereiche enthalten sein, die mit dem Attribut scope der Clientkonfiguration definiert sind. Sie müssen außerdem in der preAuthorizedScope-Liste der Clientkonfiguration angegeben sein.

In dieser Task ist beschrieben, wie ein als OpenID Connect-Provider agierender Liberty-Server für OAuth-Anforderungen mit zwei Beteiligten konfiguriert wird.

Vorgehensweise

Wenn Sie die Liste der vorab autorisierten Bereiche für einen Client angeben möchten, fügen Sie den Attributen scope und preAuthorizedScope der Clientkonfiguration im entsprechenden Element <oauthProvider> Ihrer Datei server.xml die erforderlichen Bereiche hinzu. Im gezeigten Beispiel erfüllen die Bereiche profile und email die Voraussetzungen, um in der Bereichsliste eines vom OpenID Connect-Provider zurückgegebenen Zugriffstokens angegeben zu werden. Der Bereich phone wird nicht als vorab autorisiert betrachtet, weil er in der preAuthorizedScope-Liste fehlt.
<oauthProvider id="OAuthConfigSample" ...>
 ....
           <localStore>
             <client name="client01" secret="{xor}..."
               displayname="client01"
               scope="profile email phone"
               preAuthorizedScope="profile email"
               enabled="true" />
             ....
           </localStore>
</oauthProvider>
Anmerkung: Wenn ein angeforderter Bereich nicht im Attribut scope der Clientkonfiguration aufgelistet ist, wird er von der Bereichsliste des zurückgegebenen Zugriffstokens ausgeschlossen. Wenn ein angeforderter Bereich im Attribut scope der Clientkonfiguration aufgelistet, aber nicht in der preAuthorizedScope-Liste in der Clientkonfiguration enthalten ist, löst er in der Antwort des OpenID Connect-Providers einen Fehler des Typs invalid_grant aus.

Symbol das den Typ des Artikels anzeigt. Taskartikel



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