Token Exchange-Berechtigungstyp: JSON-Web-Token für UPST austauschen

Ablauf

Haftungsausschluss: Alle Produktnamen, Logos sowie Marken und Logos sind Marken ihrer jeweiligen Inhaber und werden hier nur zu Informationszwecken verwendet.

JWT zu UPST Token Exchange Schritte

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

1. Step1: (Optional) Identitätsdomain erstellen
2. Schritt 2: Identitätsdomainanwendungen erstellen
3. Schritt 3: (Optional) Servicebenutzer verwenden
4. Schritt 4: Identity Propagation Trust-Konfiguration erstellen
5. Schritt 5: Erstellen eines Public Keys
6. Schritt 6: JWT-Token generieren, das gegen UPST ausgetauscht werden soll
7. Schritt 7: OCI UPST abrufen

Step1: (Optional) Identitätsdomain erstellen

Erstellen Sie eine neue Identitätsdomain, wenn sie nicht vorhanden ist. Siehe Identitätsdomain erstellen.

Schritt 2: Identitätsdomainanwendungen erstellen

Ein OAuth-Client ist eine vertrauenswürdige Anwendung, die bei Identity Cloud Service registriert ist, um sich mit OAuth 2.0-Abläufen zu authentifizieren und Zugriffstoken abzurufen. Mit diesem Client können Sie:

• Rufen Sie ein Zugriffstoken ab, um IDCS-Admin-APIs aufzurufen.

• Verbinden Sie die App-Identität, um JWT gegen UPST auszutauschen.

Siehe Vertrauliche Anwendung hinzufügen. Nachdem Sie die Anwendung erstellt haben, speichern Sie die Client-ID und das Client Secret an einem sicheren Ort. Sie benötigen zwei Identitätsdomainanwendungen gemäß dem Least-Privilege-Prinzip (PoLP):

• Eine Anwendung mit der IDA-(Identity Domain Administrator-)Anwendungsrolle. Mit einem mit dieser App generierten Zugriffstoken können Sie Vorgänge für Identity Propagation Trust (Schritt 4: Vertrauenskonfiguration für Identitätspropagierung erstellen) und Servicebenutzer (Schritt 3: (Optional) Servicebenutzer verwenden) ausführen.
• Eine andere Identitätsdomainanwendung ohne die Rolle "Identitätsdomainadministrator-App" oder eine Admin-Rolle. Sie verwenden Clientzugangsdaten für diese zweite Identitätsdomainanwendung, um die Tokenaustausch-API aufzurufen. Sie müssen diese Anwendung für den Tokenaustausch autorisieren, indem Sie eine Client-ID für die Anwendung in IdentityPropagationTrust konfigurieren.

Außerdem kann die Anwendung mit der erweiterten Rolle "Identitätsdomainadministrator-App" auch JWT-zu-UPST-Tokenaustausch ausführen.

Zugriffstoken mit der Rolle "Identitätsdomainadministrator" generieren

Verwenden Sie die Anwendung mit der definierten Rolle "Identitätsdomainadministrator-App", um ein Zugriffstoken zu generieren. Siehe Zugriffstoken generieren. Verwenden Sie das für CRUD-(Create, Replace, Update, Delete-)Vorgänge generierte Zugriffstoken für IdentityPropagationTrusts (Step 4: Create an Identity Propagation Trust Configuration) und Servicebenutzer (Step 3: (Optional) Use a Service User).

Schritt 3: (Optional) Servicebenutzer verwenden

Ein Servicebenutzer ist ein Identitätsdomainbenutzer ohne interaktive Anmeldeberechtigungen. Sie haben minimale Privilegien.

Servicebenutzer können Gruppen und Apps zugewiesen werden. Anwendungen können Servicebenutzer verwenden, oder der angemeldete Benutzer kann sich als Benutzer ausgeben, um ein temporäres UPST-Token zu erhalten.

Servicenutzer 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 sind nicht zulässig, und Kennwort-Policys gelten nicht.

Anforderungsbeispiel: Servicebenutzer erstellen

Im Folgenden finden Sie ein Beispiel für eine Anforderung mit den Mindestattributen, die zum Erstellen eines Servicebenutzers erforderlich sind, wobei das Attribut serviceUser auf true. gesetzt ist.

## POST on https://<domainURL>/admin/v1/Users
 
## Header:
"Authorization: Bearer <IDA_Access_Token>" \
"Content-Type: application/json"
 
## 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": "admin"
    },
    "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": "admin",
        "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 4: 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.

"oauthClients": [
 "oauthclient-id"
 ],

Request-Beispiel: Identity Propagation Trust-Konfiguration erstellen

## POST on https://<secureDomainURL>/admin/v1/IdentityPropagationTrusts
## Header:
"Authorization: Bearer <IDA_Access_Token>" \
"Content-Type: application/json"
 
## Payload:
{
  "active": true,
  "allowImpersonation": true,
  "issuer": "<<UNIQUE_ISSUER_VALUE>>",
  "name": "Token Trust JWT to UPST",
  "oauthClients": [
  "<oauthclient-id>"
  ],
  "publicCertificate": "<public_certificate_value>",
  "publicKeyEndpoint": "https://example.identityprovider.com/publickey/<publickey_value>",
  "clientClaimName": "client_claim_name",
  "clientClaimValues": [
  "<<client_claim_value>>"
  ],
  "impersonationServiceUsers": [
    {
      "rule": "sub eq *",
      "value": "<<user_id>>"
    }
  ],
  "subjectType": "User",
  "type": "JWT",
  "schemas": [
  "urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"
  ]
}

Antwortbeispiel

{
  "active": true,
  "allowImpersonation": true,
  "issuer": "<<UNIQUE_ISSUER_VALUE>>",
  "name": "Token Trust JWT to UPST",
  "oauthClients": [
  "<oauthclient-id>"
  ],
  "publicCertificate": "<public_certificate_value>",
  "publicKeyEndpoint": "https://example.identityprovider.com/publickey/<publickey_value>",
  "clientClaimName": "client_claim_name",
  "clientClaimValues": [
  "<<client_claim_value>>"
  ],
  "subjectType": "User",
  "type": "JWT",
  "schemas": [
  "urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"
  ]
}

Anforderungsbeispiel: Für allowImpersonation auf false Identity Propagation Trust-Konfiguration gesetzt

{
    "active": true,
    "allowImpersonation": false,
    "issuer": "<<issuer_value>>",
    "name": "Token Trust JWT to UPST",
    "oauthClients": [
        "25d123....."
    ],
    "publicKeyEndpoint": "https://<<secureDomainURL>>/admin/v1/SigningCert/jwk",
    "clientClaimName": "client_name",
    "clientClaimValues": ["<<client_name_value>>"],
    "subjectClaimName": "sub",
    "subjectMappingAttribute": "userName",
    "subjectType": "User",
    "type": "JWT",
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"
    ]
}

Anforderungsbeispiel: Identity Propagation Trust-Konfiguration abrufen

## GET on https://<secureDomainURL>/admin/v1/IdentityPropagationTrusts/{{id}}
## Header:
"Authorization: Bearer <IDA_Access_Token>"

Wenn allowImpersonation auf "true" gesetzt ist und impersonationServiceUsers im Identity Propagation Trust definiert ist, verwenden Sie das folgende Anforderungsbeispiel.

## GET on https://<secureDomainURL>/admin/v1/IdentityPropagationTrusts/{{id}}?attributes=impersonationServiceUsers
## Header:
"Authorization: Bearer <IDA_Access_Token>"

Antwortbeispiel

{
  "active": true,
  "allowImpersonation": true,
  "issuer": "<<UNIQUE_ISSUER_VALUE>>",
  "name": "Token Trust JWT to UPST",
  "oauthClients": [
  "<oauthclient-id>"
  ],
  "publicCertificate": "<public_certificate_value>",
  "publicKeyEndpoint": "https://example.identityprovider.com/publickey/<publickey_value>",
  "clientClaimName": "client_claim_name",
  "clientClaimValues": [
  "<<client_claim_value>>"
  ],
  "subjectClaimName": "sub",
  "subjectMappingAttribute": "userName",
  "subjectType": "User",
  "type": "JWT",
  "impersonationServiceUsers": [
  {
       "ocid": "ocid1.user.oc1..this.is.user.ocid",
       "rule": "sub eq *",
       "value": "<<user_id>>",
       "$ref": "https://<<secureDomainURL>>/admin/v1/Users/<<user_id>>"
  }
  "schemas": [
  "urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"
  ]
}

Schritt 5: Erstellen eines Public Keys

Verwenden Sie die folgenden Befehle in einem Terminal (Linux/macOS) oder in Git Bash unter Windows:

# Generate a 2048-bit RSA private key
openssl genrsa -out private_key.pem 2048
 
# Extract the public key in PEM format
openssl rsa -in private_key.pem -pubout -out public_key.pem

Nach Ausführung der folgenden Aktionen:

• private_key.pem ist der Private Key, mit dem das JWT signiert wird.

• public_key.pem ist der Public Key, der von OCI zur Prüfung der JWT-Signatur verwendet wird.

Schritt 6: JWT-Token generieren, das gegen UPST ausgetauscht werden soll

Generieren Sie ein JWT-Token mit dem OCI-Workflow für Kennwortzugangsdaten für Ressourceneigentümer, dem Workflow für Clientzugangsdaten und dem Workflow für Benutzer-Assertion oder mit einem beliebigen externen IdPs, wie Microsoft Entra ID, Google Firebase Authentication, AWS Cognito, Okta und anderen. Das generierte JWT-Token:

• Enthält Ansprüche über den Benutzer oder die Arbeitslast.

• Wird vom Private Key des IdP signiert, damit OCI seine Authentizität mit dem Public Key prüfen kann.

• Wird am Sicherheitstokenendpunkt von OCI gegen einen UPST ausgetauscht.

Schritt 7: OCI UPST abrufen

JWT wird am OCI-Tokenaustauschendpunkt ausgetauscht. Der Tokenendpunkt decodiert und verifiziert die JWT-Signatur mit dem Public Key aus der Trust-Konfiguration, validiert den Aussteller und übereinstimmende Claims gemäß der Definition im Identity Propagation Trust und generiert UPST.

Der empfangene UPST wird für den Zugriff auf Ressourcen mit OCI-SDK/API verwendet.

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=jwt' -k
{
   "token": "<token_id>"
}