Oracle Cloud Infrastructure - Dokumentation

Berechtigungstyp "Assertion"

Verwenden Sie diesen Berechtigungstyp, wenn Sie eine vorhandene Vertrauensstellung als Assertion ohne direkten Benutzergenehmigungsschritt auf dem OAuth-Autorisierungsserver verwenden möchten.

Das folgende Diagramm zeigt den Ablauf "Assertion-Berechtigungstyp".

Ein Diagramm, das den Ablauf "Assertion-Berechtigungstyp" veranschaulicht.

In diesem OAuth-Fluss:

  1. Ein Benutzer versucht, auf eine Clientanwendung zuzugreifen und eine generierte Benutzer-Assertion zu senden.
    Hinweis

    Der Prozess zur Erfassung der Assertion liegt außerhalb des Geltungsbereichs für diese Erklärung.

  2. Die Clientanwendung fordert ein Zugriffstoken und häufig ein Aktualisierungstoken an, indem sie eine Benutzer-Assertion oder eine Drittanbieter-Benutzer-Assertion und Clientzugangsdaten bereitstellt.

  3. Der Autorisierungsserver gibt das Zugriffstoken an die Clientanwendung zurück.

  4. Die Clientanwendung verwendet das Zugriffstoken in einem API-Aufruf, um geschützte Daten wie eine Benutzerliste abzurufen.

Funktion Verfügbar
Clientauthentifizierung erforderlich Ja
Client muss Benutzerzugangsdaten kennen Nein
Browserbasierte Endbenutzerinteraktion

Hinweis: Der Prozess zum Generieren der Assertion kann eine Benutzerinteraktion beinhalten.

 Nein
Kann externen Identitätsprovider zur Authentifizierung verwenden Ja
Tokenaktualisierung ist zulässig Ja
Zugriffstoken befindet sich im Kontext des Endbenutzers

Ein Zugriffstoken befindet sich im Kontext des Subjects der Assertion, bei dem es sich um einen Endbenutzer, einen Service oder den Client selbst handeln kann.

 Vielleicht

Siehe ein Beispiel für den Autorisierungsablauf des Assertion-Berechtigungstyps.

Beispiel für Autorisierungsablauf des Assertion-Berechtigungstyps

In diesem Beispielablauf hat Example.com mehrere Oracle Cloud-Anwendungen PaaS und SaaS abonniert. Example.com-Benutzer möchten auf Oracle Cloud-Eigenschaften zugreifen können, ohne den Autorisierungsprozess selbst durchlaufen zu müssen (delegierte Autorisierung).

Hinweis

Der Befehl in diesem Beispiel verwendet die URL-Struktur https://<domainURL>/resource-path, wobei <domainURL> die Identity Service-URL und der Ressourcenpfad die Identity Service-API darstellt. Die entsprechende URL-Struktur finden Sie unter Anforderungen senden.
Wenn Sie eine Anwendung mit dem Berechtigungstyp "Assertion" in der Identitätsdomainkonsole erstellen:

  • Geben Sie App als Anwendungstyp an.

  • Wählen Sie Assertion als Berechtigungstyp aus.

Weitere Informationen zum Berechtigungstyp "Assertion" und einem Autorisierungsablaufdiagramm finden Sie unter Berechtigungstyp "Assertion".

Autorisierungsablauf

  1. Ein Benutzer versucht, auf eine Clientanwendung (wie JCS) zuzugreifen.

    Die URL enthält Abfrageparameter, die den angeforderten Zugriffstyp angeben. Die SAML2-Assertion ist Base64-codiert, und der Empfängerwert in der SAML-Assertion muss einer der folgenden Werte sein:

    • Der Aussteller im Feld "Aussteller" der OAuth-Einstellungen in der Benutzeroberfläche.
    • Oder https://<domainURL>/.
    • Oder der Wert von secure_saml_sp_sso_endpoint in der Discovery-Antwort.
    Beispielanforderung mit dem Autorisierungsheader
       curl -i
   -H 'Authorization: Basic <base64Encoded clientid:secret>'
   -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
   --request POST https://<domainURL>/oauth2/v1/token 
   -d 'grant_type=password&username=<user-name>&password=<example-password>&scope=<scope value>'

    Beispielanforderung mit Autorisierungsheader und Aktualisierungstoken in Anforderung

       curl -i
   -H 'Authorization: Basic <base64Encoded clientid:secret>'
   -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
   --request POST https://<domainURL>/oauth2/v1/token 
   -d 'grant_type=password&username=<user-name>&password=<example-password>&scope=<Resource Server Scope>%20offline_access'

    Beispielanforderung mit einer JWT-Client-Assertion

       curl -i
   -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
   --request POST https://<domainURL>/oauth2/v1/token 
   -d 'grant_type=password&username=<user-name>&password=<example-password>&client_id=<client-id>&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<client-assertion>&scope=<scope value>'

    Beispielanforderung mit einer JWT-Client-Assertion, die Aktualisierungstoken in Anforderung einschließt

       curl -i
   -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
   --request POST https://<domainURL>/oauth2/v1/token 
   -d 'grant_type=password&username=<user-name>&password=<example-password>&client_id=<client-id>&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<client-assertion>&scope=<Resource Server Scope>%20offline_access'

  2. Ein Oracle Web Services Manager-(client-seitiger) Agent fängt die Clientanwendung ab und ruft einen REST-API-Aufruf an den Ressourcenserver (Fusion-Anwendungen) ab, um ein Zugriffstoken abzurufen.

  3. Der Autorisierungsserver OAuth authentifiziert die Clientanwendung basierend auf dem Autorisierungsheader oder der gesendeten Assertion und gibt ein Zugriffstoken zurück, das alle anwendbaren Geltungsbereiche enthält, basierend auf den Berechtigungen, die durch die Anwendungsrollen dargestellt werden, die der anfordernden Clientanwendung erteilt wurden.

  4. Der Benutzer kann über eine andere OPC-Anwendung auf eine OPC-Anwendung zugreifen.