Berechtigungstyp "Tokenaustausch": Kerberos-Token für UPST austauschen

Verwenden Sie den Kerberos-Tokenaustausch, bei dem Kerberos der Authentifizierungsprovider ist und Sie Kerberos-Token gegen IAM-Token oder -Principals austauschen müssen, um auf OCI-Services zuzugreifen. Sie tauschen Kerberos-Token für OCI-Benutzer-Principal-Sessiontoken (UPST) in IAM aus.

Kerberos-Tokenbedingungen
Begriff Beschreibung
Kerberos

Eine plattformübergreifende Authentifizierung und ein Single Sign-On-System. Das Kerberos-Protokoll bietet gegenseitige Authentifizierung zwischen zwei Entitys, die sich auf ein Shared Secret (symmetrische Schlüssel) verlassen. Die Kerberos-Authentifizierung erfordert einen Client, einen Server und eine vertrauenswürdige Partei, um zwischen ihnen zu vermitteln, die als Key Distribution Center (KDC) bezeichnet werden.

Folgendes ist ebenfalls erforderlich:

  • Ein Principal: Eine Identität für einen Benutzer (einem Benutzer wird ein Principal zugewiesen) oder eine Identität für eine Anwendung, die Kerberos-Services anbietet.

  • Eine Realm: Eine Kerberos-Serverumgebung, bei der es sich um einen Domainnamen wie example.com handeln kann. Jede Kerberos-Realm verfügt über mindestens ein Web Services Security KDC.

Mit dem Kerberos Token-Profil von WS-Security können Geschäftspartner Kerberos-Token in serviceorientierten Architekturen (SOAs) verwenden.

Kerberos Schlüsselverteilungscenter (KDC) Ein Authentifizierungsserver eines Drittanbieters.
Active Directory (AD) Ein Repository für den KDC-Server.
Schlüsseltabelle

Eine Datei, in der der tatsächliche Verschlüsselungsschlüssel gespeichert wird, der anstelle einer Kennwortherausforderung für einen bestimmten Principal verwendet werden kann. Keytab-Dateien sind für nicht interaktive Anwendungsfälle nützlich.

Tipp: Mit dem KDC-Admin-Tool kann eine Schlüsseltabellendatei erstellt werden. Beim Erstellen der Schlüsseltabelle kann der Verschlüsselungstyp angegeben werden. Verwenden Sie den folgenden Verschlüsselungstyp: aes256-cts-hmac-sha1-96.

Einfacher und geschützter GSSAPI Verhandlungsmechanismus (SPNEGO)

Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) ist ein GSSAPI "Pseudo-Mechanismus", der von Client/Server-Software verwendet wird, um die Wahl der Sicherheitstechnologie auszuhandeln.

Kerberos-Tickets werden als Teil des SPNEGO-Tokens gewrappt, sodass das Token mit der HTTP-basierten Anwendungsschicht funktioniert.

SPNEGO-Tokenformat und -Details

Das SPNEGO-Tokenformat wird in RFC 4178 definiert. Das Token ist eine serialisierte Datenstruktur, die folgende Felder enthält:

  • mechTypes: Eine Folge von Objekt-IDs (OID), in der die unterstützten Authentifizierungsverfahren aufgeführt werden.
  • mechToken: Ein optimistisches Mechanismustoken. Dies ist ein Token, mit dem der tatsächliche Authentifizierungsmechanismus ausgehandelt wird, der verwendet wird.
  • krb5Creds: Ein Kerberos-Blob. Dies ist ein Binärblob, der die Kerberos-Authentifizierungsinformationen enthält.

Das SPNEGO-Token wird in ASN.1 codiert. Im Folgenden finden Sie ein Beispiel für ein SPNEGO-Token:

NegTokenInit ::= SEQUENCE
{
mechTypes SEQUENCE OF Oid,
mechToken OCTET STRING,
krb5Creds [0] KerberosCreds OPTIONAL
}
GSSAPI Allgemeine Security Services-Anwendungsprogrammschnittstelle
IAM Token Exchange Service-API IAM-Identitätsdomainservice OAuth: /oauth2/v1/token. Die API akzeptiert sowohl standardmäßige OAuth-basierte Authentifizierungsheader/-Payload als auch OCI-Signaturen. Informationen zum Verwenden eines OAuth-Clients mit einer Identitätsdomain für den Zugriff zu den REST-APIs finden Sie unter REST-API mit OAuth 2 aufrufen.
Vertrauenskonfiguration für Identitätspropagierung Verwenden Sie Identity Propagation Trust-Konfigurationen, um die Vertrauenswürdigkeit zwischen OCI Identity und einem externen Identitätsprovider herzustellen und das externe Identitätsprovider-Token sowie die Zuordnung der Benutzeridentität des externen Identitätsproviders zur Benutzeridentität in IAM zu validieren. Identity Propagation Trust erleichtert auch die Identitätspropagierung von einem externen Identitätsprovider in OCI. Das /IdentityPropagationTrust-Endpunktdesign ist generisch und funktioniert mit jedem Cloud-Provider. Informationen zum Erstellen einer Trust-Konfiguration für die Identitätspropagierung finden Sie unter Schritt 6: Vertrauenskonfiguration für Identitätspropagierung erstellen.
Servicebenutzer Ein Benutzer ohne interaktive Anmeldeberechtigungen. Diese Servicebenutzer können Gruppen und Servicerollen erteilt werden. Anwendungen können diese Servicebenutzer verwenden, oder der angemeldete Benutzer kann sich als Benutzer ausgeben, um einen temporären UPST zu erhalten. Die Verwendung eines Servicebenutzers ist optional. Weitere Informationen zur Verwendung von Servicebenutzern finden Sie in Schritt 5: Servicebenutzer verwenden (optional).
Benutzer-Principal-Sessiontoken (UPST) Ein von IAM generiertes Token. Wird auch als Sicherheitstoken bezeichnet. Es stellt den authentifizierten Servicebenutzer dar.

Schritte für den Kerberos-Tokenaustausch

Führen Sie die folgenden Schritte aus, um ein Kerberos-Token gegen ein UPST auszutauschen:

  1. Schritt 1: Vault erstellen und Inhalt der Keytab-Datei hinzufügen
  2. Schritt 2: Erforderliche IAM-Policy erstellen
  3. Schritt 3: Identitätsdomainanwendung erstellen
  4. Schritt 4: SPNEGO-Token für einen bestimmten Benutzer-Principal generieren
  5. Schritt 5: Servicebenutzer verwenden (optional)
  6. Schritt 6: Identity Propagation Trust-Konfiguration erstellen
  7. Schritt 7: OCI UPST abrufen

Schritt 1: Vault erstellen und Inhalt der Keytab-Datei hinzufügen

Erstellen Sie einen Vault, und fügen Sie den Inhalt der Keytab-Datei als base64-codierte Zeichenfolge hinzu. Hinweis: IAM speichert die Keytab-Datei nicht in ihrem Dateisystem.

Verwenden Sie die folgenden Schritte als Leitfaden:

  1. Vault erstellen. Siehe Vault erstellen.
  2. Lesen Sie den Inhalt der Schlüsseltabelle im Format Base64.
  3. Gehen Sie zum Vault, und speichern Sie ihn unverändert. Prüfen Sie Base64 beim Erstellen des Secrets als Secret-Typvorlage. Siehe Secret in einem Vault erstellen.

Schritt 2: Erforderliche IAM-Policy erstellen

Erstellen Sie eine IAM-Policy im Mandanten, damit eine Identitätsdomainressource auf Vault zugreifen kann. Dadurch kann IAM die Schlüsseltabellenkonfiguration aus Vault abrufen. Verwenden Sie das folgende Beispiel als Leitfaden:

allow resource domain <domain_displayName> to read secrets from vault in compartment <compartment_ocid> where all {target.secret.id = <secret_ocid_where_the_keytab_is_present>}

Schritt 3: Identitätsdomainanwendung erstellen

Erstellen Sie eine vertrauliche Anwendung für die Identitätsdomain. Nachdem Sie die Anwendung erstellt haben, speichern Sie die Client-ID und das Client Secret an einem sicheren Ort. Siehe Vertrauliche Anwendung hinzufügen.

Schritt 4: SPNEGO-Token für einen bestimmten Benutzer-Principal generieren

  1. Verwenden Sie Java-Code, um eine Verbindung zum KDC-Server herzustellen und das SPNEGO-Token zu generieren.
  2. Kopieren Sie dieses SPNEGO-Token, um die Tokenanforderung zu bilden.

Verwenden Sie das folgende Java-Codebeispiel als Leitfaden:

package com.oracle;

import com.sun.security.auth.module.Krb5LoginModule;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import org.ietf.jgss.Oid;

import javax.security.auth.Subject;
import java.io.IOException;
import java.security.Principal;
import java.security.PrivilegedAction;
import java.util.Base64;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;

public class GenerateSpnegoToken {
    static String servicePrincipal = "HTTP/iamtesp@WINDOWSKDCSERVER.COM";
    static String userPrincipal = "HTTP/<sample-job>@WINDOWSKDCSERVER.COM";
    static String userPrincipalKeyTab = "keytabs/ms/<sample-job>.keytab";
    public static void main(String[] args) throws IOException {
        System.setProperty("sun.security.krb5.debug", "true");
        System.setProperty("sun.security.spnego.debug", "true");
        System.setProperty("java.security.krb5.conf", "ms_krb5.conf");

        String spnegoToken = generateSpnegoToken();
    }
    private static String generateSpnegoToken() {
        Subject subject = getAuthenticateSubject();
        return Subject.doAs(
                subject,
                (PrivilegedAction<String>)
                        () -> {
                            String SPNEGO_OID = "1.3.6.1.5.5.2";
                            String KRB5_MECHANISM_OID = "1.2.840.113554.1.2.2";
                            String KRB5_PRINCIPAL_NAME_OID = "1.2.840.113554.1.2.2.1";

                            try {
                                // Create GSS context for the service principal and the logged-in user
                                Oid krb5Mechanism = new Oid(KRB5_MECHANISM_OID);
                                Oid krb5PrincipalNameType = new Oid(KRB5_PRINCIPAL_NAME_OID);
                                Oid spnegoOid = new Oid(SPNEGO_OID);
                                GSSManager manager = GSSManager.getInstance();
                                GSSName gssServerName =
                                        manager.createName(servicePrincipal, krb5PrincipalNameType, krb5Mechanism);
                                GSSContext gssContext =
                                        manager.createContext(
                                                gssServerName, spnegoOid, null, 240000);
                                gssContext.requestMutualAuth(true);
                                gssContext.requestCredDeleg(true);
                                gssContext.requestLifetime(10);

                                // Generate the SPNEGO token
                                byte[] token = new byte[0];
                                token = gssContext.initSecContext(token, 0, token.length);
                                return Base64.getEncoder().encodeToString(token);
                            } catch (GSSException e) {
                                throw new RuntimeException(e);
                            }
                        });
    }

    private static Subject getAuthenticateSubject() {
        final Map<String, String> options = new HashMap<>();
        options.put("keyTab", userPrincipalKeyTab);
        options.put("principal", userPrincipal);
        options.put("doNotPrompt", "true");
        options.put("isInitiator", "true");
        options.put("refreshKrb5Config", "true");
        options.put("storeKey", "true");
        options.put("useKeyTab", "true");

        // Execute the login
        Subject subject = new Subject();
        Krb5LoginModule krb5LoginModule = new Krb5LoginModule();
        krb5LoginModule.initialize(subject, null, new HashMap<String, String>(), options);
        try {
            krb5LoginModule.login();
            krb5LoginModule.commit();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
        Set<Principal> principals = (Set<Principal>) subject.getPrincipals();
        Iterator<Principal> iterator = principals.iterator();
        while (iterator.hasNext()) {
            System.out.println("\nprincipal : " + ((Principal) iterator.next()));
        }

        return subject;

    }
}

Schritt 5: Servicebenutzer verwenden (optional)

Ein Servicebenutzer ist ein Identitätsdomainbenutzer, bei dem das Attribut serviceUser auf true gesetzt ist.

Hinweis

Die Verwendung eines Servicebenutzers ist optional. Wenn die Benutzerimpersonation als Teil der Trust-Konfiguration verwendet wird, sind Servicebenutzer erforderlich. Andernfalls wird ein anderer Identitätsdomainbenutzer verwendet. Nur Identitätsdomainadministratoren können einen Servicebenutzer erstellen, ersetzen, aktualisieren oder löschen. Andere Administratoren können Servicebenutzer und ihre Attribute lesen.

Um einen Servicebenutzer zu verwenden, erstellen Sie einen Benutzer ohne interaktive Anmeldeberechtigungen. Diese Servicebenutzer können Gruppen und Servicerollen erteilt werden. Ihre Anwendungen können diese Servicebenutzer verwenden, oder der angemeldete Benutzer kann sich als Benutzer ausgeben, um ein temporäres UPST-Token zu erhalten.

Servicebenutzer weisen folgende Merkmale auf:

  • Muss ein userName-Token enthalten. Vorname und Nachname sind nicht erforderlich.
  • Kann eine E-Mail-Adresse haben (optional).
  • kann Mitglied von Gruppen und Anwendungsrollen sein.
  • API-Schlüssel nicht zulässig.
  • Selfserviceendpunkte können nicht verwendet werden.
  • Kennwörter und Kennwort-Policys können nicht angewendet werden.

Anforderungsbeispiel: Servicebenutzer erstellen

Im Folgenden finden Sie ein Beispiel für eine Anforderung mit den Mindestattributen, die zum Erstellen eines Servicebenutzers erforderlich sind.

## POST on https://<domainURL>/admin/v1/Users
## Payload:
{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User": {
        "serviceUser": true
    },
    "userName": "myServiceUserName"
}

Antwortbeispiel: Servicebenutzer erstellen

Im Folgenden finden Sie ein Beispiel für eine Antwort beim Erstellen eines Servicebenutzers.

{
    "idcsCreatedBy": {
        "type": "App",
        "display": "idcsadmin"
    },
    "id": "<user_id>",
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User": {
        "isFederatedUser": false,
        "isGroupMembershipSyncedToUsersGroups": true,
        "serviceUser": true
    },
    "meta": {
        "created": "2023-12-07T06:52:55.380Z",
        "lastModified": "2023-12-07T06:52:55.380Z",
        "version": "<version>",
        "resourceType": "User",
        "location": "https://<domainURL>/admin/v1/Users/<user_id>"
    },
    "active": true,
    "idcsLastModifiedBy": {
        "display": "idcsadmin",
        "type": "App"
    },
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User": {
        "locked": {
            "on": false
        }
    },
    "ocid": "ocid1.user.region1...<ocid>",
    "userName": "myServiceUserName",
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User",
        "urn:ietf:params:scim:schemas:oracle:idcs:extension:capabilities:User",
        "urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User"
    ]
}

Schritt 6: Identity Propagation Trust-Konfiguration erstellen

Mit der Identity Propagation Trust-Konfiguration wird die Vertrauensstellung zwischen OCI Identity und den externen Cloud-Providern, die Validierung des Cloud-Providertokens und die Zuordnung der Benutzeridentität des Cloud-Providers zur Benutzeridentität der Identitätsdomains service hergestellt.

Detaillierte Beschreibung einer Identity Propagation Trust-Konfiguration
Attribut Obligatorisch? Beschreibungen und Beispiele
Name Ja

Der Name der Vertrauensstellung.

Typ Ja

Der Tokentyp:

  • Spnego
  • JWT
  • saml
  • aws-Zugangsdaten
Aussteller Ja

Verwenden Sie den Aussteller, um die Trust-Identifikation zu finden. Beispiel: Wenn das SPNEGO-Token mit dem Service-Principal IAMSp generiert wird, ist IAMSp der Ausstellerwert.

Beispiel: IAMTokenExchangeServicePrincipal

Aktiv Ja

Wenn aktiviert, true.

Wenn deaktiviert, false.

oauthClients Ja

Eine Liste der OAuth-Clients, die Token für einen bestimmten vertrauenswürdigen Partner abrufen dürfen.

Beispiel:
"oauthClients": [
 "oauthclient-id"
 ],
allowImpersonation (verwenden Sie serviceUser) Nein

Boolescher Wert. Gibt an, ob der resultierende UPST den authentifizierten Benutzer als Subjekt enthalten soll oder ob er sich als Servicebenutzer in IAM ausgeben soll.

impersonatingServiceUser

Ja, wenn allowImpersonation auf true gesetzt ist.

Gibt an, welcher resultierende Principal basierend auf dem Tokenanspruchsnamen und den Wertbedingungen impersoniert. Sie können:

  • Lassen Sie einen bestimmten imitierenden Principal für alle authentifizierten Benutzer des Identitätsproviders (IdP) zu.
  • Regeln zum Definieren von Impersonierungsbedingungen festlegen:
    • Basierend auf dem Tokenanspruchsnamen
    • Bedingung: enthält (co) oder ist gleich (eq)
    • Wert:
      • Kann eine Zeichenfolge sein.
      • Wertearray und komplexe/zusammengesetzte Werte werden nicht unterstützt.
      • Bedingung gleich: Platzhalter (*) ist zulässig.
      • Bedingung enthält: Platzhalter (*) wird nicht unterstützt.
    • Es wird ein Principal ausgegeben.

Beispiel:

  • Regel: "username" eq kafka*
  • Zugeordneter Servicebenutzer: kafka
  • Ergebnis: Alle authentifizierten Benutzer, die mit dem Präfix kafka beginnen, werden mit dem IAM-Servicebenutzer kafka impersoniert. Der resultierende UPST enthält kafka als authentifizierten Benutzer-Principal.

Wenn die Impersonierung zulässig ist, weist das resultierende OCI-Sicherheitstoken (UPST) den ursprünglichen authentifizierten benutzerbezogenen Claim (source_authn_prin) auf, der auch angibt, in wem Namen die Impersonierung erfolgt.

  • Wenn der Betreffanspruchsname konfiguriert ist, wird er verwendet, um diesen Anspruchswert zu extrahieren.
  • Wenn der Subject Claimname nicht konfiguriert ist, wird im eingehenden Token standardmäßig sub verwendet. Wenn der sub-Anspruch selbst nicht vorhanden ist, wird er ignoriert.
Die Auswertung wird mit der ersten übereinstimmenden Regel gestoppt, und der entsprechende resultierende Principal wird mit dem Attribut "Anzeigename" zurückgegeben. Wenn keine Regeln übereinstimmen, verläuft die Tokenanforderung mit Fehlern nicht erfolgreich.
Schlüsseltabelle

Ja, wenn der Tokentyp SPNEGO lautet.

Ruft die Keytab-Konfiguration aus Vault ab.

Wichtig:
  • Der Tokenaustausch-Service ruft die Secret-Informationen basierend auf der Secret-OCID und der Secret-Version ab.

  • Wenn die Schlüsseltabelle im KDC-Server rotiert wird, müssen Sie die Secret-Informationen in der Identity Propagation Trust-Konfiguration aktualisieren.

  • Wenn die Schlüsseltabelle in Vault rotiert wird, müssen Sie die Secret-Informationen in der Identity Propagation Trust-Konfiguration aktualisieren.

Request-Beispiel: Identity Propagation Trust-Konfiguration erstellen

Im Folgenden finden Sie ein Beispiel für eine Anforderung zum Erstellen einer Identity Propagation Trust-Konfiguration.
## POST on https://<domainURL>/admin/v1/IdentityPropagationTrusts
## Payload:
{
 "active": true,
 "allowImpersonation": false,
 "issuer": "idcs_psr_itp",
 "name": "<identity_propagation_trust_name>",
 "oauthClients": [
 "<oauthclient-id>"
 ],
 "keytab": {
 "secretOcid": "<secret_ocid>"
 },
 "subjectMappingAttribute": "userName",
 "subjectType": "User",
 "type": "SPNEGO",
 "schemas": [
 "urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"
 ]
}

Antwortbeispiel: Trust-Konfiguration für Identity Propagation erstellen

Im Folgenden finden Sie ein Beispiel für eine Antwort beim Erstellen einer Identity Propagation Trust-Konfiguration.
  "response": {
    "name": "<identity_propagation_trust_name>",
    "type": "<token_type>",
    "issuer": "idcs_psr_itp",
    "accountId": "<example_account_id>",
    "subjectClaimName": "cognito:username",
    "subjectMappingAttribute": "username",
    "subjectType": "User",
    "clientClaimName": "appId",
    "clientClaimValues": ["<client_claim_value>"],
    "active": true,
    "publicKeyEndpoint": "https://example.identityprovider.com/publickey/<publickey_value>",
    "publicCertificate": "<public_certificate_value>",
    "oauthClients": ["<oauthclient-id>"],

    "allowImpersonation": true,
    "impersonationServiceUsers": [
      {
        "rule": "groups co \"network-admin\"",
        "value": "<user_id>"
      },
      {
        "rule": "groups co \"tenancy-admin\"",
        "value": "<user_id>"
      }
    ],
    "keytab": {
      "secretOcid": "<secret_ocid>",
      "secretVersion": "<secret_version>"
    },
    "clockSkewSeconds": 60,
    "id": "<identity_propagation_trust_id>",
    "meta": {
      "created": "2023-11-09T23:26:53.224Z",
      "lastModified": "2023-11-09T23:26:53.224Z",
      "resourceType": "IdentityPropagationTrust",
      "location": "http://example.hostname.com:8990/admin/v1/IdentityPropagationTrusts/<identity_propagation_trust_id>"
    },
    "schemas": [
      "urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"
    ],
    "idcsCreatedBy": {
      "value": "<app_id>",
      "display": "admin",
      "type":"App",
      "$ref": "http://example.hostname.com:8990/admin/v1/Apps/<app_id>"
    },
    "idcsLastModifiedBy": {
      "value": "<app_id>",
      "display": "admin",
      "type":"App",
      "$ref": "http://example.hostname.com:8990/admin/v1/Apps/<app_id>"
    }
  }

Schritt 7: OCI UPST abrufen

Detaillierte Beschreibung der UPST-Tokenanforderungs-Payload
Anforderungsparameter Gültig

grant_type

'grant_type=urn:ietf:params:oauth:grant-type:token-exchange'

requested_token_type

'requested_token_type=urn:oci:token-type:oci-upst'

public_key

'public_key=<public-key-value>'

Der Public Key-Workflow:

  1. Die Workload generiert ein Schlüsselpaar.
  2. Der Public Key wird als Teil einer Tokenaustauschanforderung gesendet, die als Claim jwk in das resultierende UPST eingefügt wird.
  3. Mit dem Private Key werden die OCI-Signaturen für den API-Aufruf der OCI-nativen Services zusammen mit dem UPST generiert.
  4. Die OCI-Serviceauthentifizierung validiert den UPST, extrahiert den jwk-Claim aus dem UPST und verwendet ihn dann zur Validierung der OCI-Signatur.

subject_token_type

'subject_token_type=spnego'

  • Spnego
  • JWT
  • saml
  • aws-Zugangsdaten

subject_token

'subject_token=<subject-token>'

Wenn der Tokentyp:

  • spnego: Das undurchsichtige verschlüsselte Token.
  • jwt oder saml: Der Assertion-Wert jwt oder saml unverändert.
  • aws-credential: Der base64-codierte Wert der AWS-Zugangsdaten, die im XML-Format angezeigt werden.

issuer

Erforderlich, wenn der Tokentyp spnego lautet.

Beispiel:

IAMTokenExchangeServicePrincipal

Beispiel für UPST-Tokenanforderung: OCI-signaturbasiert

Im Folgenden finden Sie ein Beispiel für eine OCI-signaturbasierte cURL-Anforderung.

## OCI Signature Based Request
curl  -X POST -sS https://<domainURL>/oauth2/v1/token -i 
-H 'date: Wed, 06 Dec 2023 01:17:33 GMT' 
-H 'x-content-sha256: <key>' 
-H 'content-type: application/x-www-form-urlencoded;charset=utf-8' 
-H 'content-length: 197' 
-H 'Authorization: Signature version="1",keyId="<key_id>",algorithm="rsa-sha256",headers="(request-target) date host x-content-sha256 content-type content-length",signature="a+aH0b...TLtPA=="'  --data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
--data-urlencode 'requested_token_type=urn:oci:token-type:oci-upst' \
--data-urlencode 'public_key=<public_key>' \
--data-urlencode 'subject_token=<subject_token>' \
--data-urlencode 'subject_token_type=spnego' \
--data-urlencode 'issuer=<Issuer stored in the Identity Trust Propagation. For example, examplead@kdcserver.com>' -k
{
   "token": "<token_id>"
}

Beispiel für UPST-Tokenanforderung: App-basiert für Identitätsdomain

Im Folgenden finden Sie ein Beispiel für eine anwendungsbasierte OCI-Identitätsdomain-cURL-Anforderung.

## IAM Domain App Based Request. Note that client credentials can be sent as part of basic authn header or in the payload.  
curl --location ' https://<domainURL>/oauth2/v1/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic <auth_code>' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
--data-urlencode 'requested_token_type=urn:oci:token-type:oci-upst' \
--data-urlencode 'public_key=<public_key>' \
--data-urlencode 'subject_token=<subject_token>' \
--data-urlencode 'subject_token_type=spnego' \
--data-urlencode 'issuer=<Issuer stored in the Identity Trust Propagation. For example, examplead@kdcserver.com>' -k
{
   "token": "<token_id>"
}