Liberty-Repository[8.5.5.4 oder höher]

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 Autorisierungsserver. 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 Autorisierungsserver 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 automatisch zum Anforderungstoken hinzugefügt, das dann an den Autorisierungsserver gesendet wird.

Vorbereitende Schritte

Bei dieser Task wird davon ausgegangen, dass Ihr Liberty Profile-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 zweigliedrige HTTP-Anforderung 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 jedoch dennoch die autorisierten Bereiche in seinem access_token-Inhalt bearbeiten.

Als OpenID Connect-Provider konfigurierte Liberty Profile-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 Profile-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 die erforderlichen Bereiche zu den Attributen scope und preAuthorizedScope der Clientkonfiguration im entsprechenden Element <oauthProvider> Ihrer Datei server.xml 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

Nutzungsbedingungen für Information Center | Feedback


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