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.
| 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:
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: |
| 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:
Das SPNEGO-Token wird in ASN.1 codiert. Im Folgenden finden Sie ein Beispiel für ein SPNEGO-Token:
|
| 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:
- Schritt 1: Vault erstellen und Inhalt der Keytab-Datei hinzufügen
- Schritt 2: Erforderliche IAM-Policy erstellen
- Schritt 3: Identitätsdomainanwendung erstellen
- Schritt 4: SPNEGO-Token für einen bestimmten Benutzer-Principal generieren
- Schritt 5: Servicebenutzer verwenden (optional)
- Schritt 6: Identity Propagation Trust-Konfiguration erstellen
- 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:
- Vault erstellen. Siehe Vault erstellen.
- Lesen Sie den Inhalt der Schlüsseltabelle im Format Base64.
- 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
- Verwenden Sie Java-Code, um eine Verbindung zum KDC-Server herzustellen und das SPNEGO-Token zu generieren.
- 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.
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.
| Attribut | Obligatorisch? | Beschreibungen und Beispiele |
|---|---|---|
| Name | Ja |
Der Name der Vertrauensstellung. |
| Typ | Ja |
Der Tokentyp:
|
| Aussteller | Ja |
Verwenden Sie den Aussteller, um die Trust-Identifikation zu finden. Beispiel: Wenn das SPNEGO-Token mit dem Service-Principal Beispiel: |
| Aktiv | Ja |
Wenn aktiviert, Wenn deaktiviert, |
| oauthClients | Ja |
Eine Liste der OAuth-Clients, die Token für einen bestimmten vertrauenswürdigen Partner abrufen dürfen. Beispiel:
|
| 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 |
Gibt an, welcher resultierende Principal basierend auf dem Tokenanspruchsnamen und den Wertbedingungen impersoniert. Sie können:
Beispiel:
Wenn die Impersonierung zulässig ist, weist das resultierende OCI-Sicherheitstoken (UPST) den ursprünglichen authentifizierten benutzerbezogenen Claim (
|
| Schlüsseltabelle |
Ja, wenn der Tokentyp |
Ruft die Keytab-Konfiguration aus Vault ab. Wichtig:
|
Request-Beispiel: Identity Propagation Trust-Konfiguration erstellen
## 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
"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
| Anforderungsparameter | Gültig |
|---|---|
|
|
|
|
|
|
|
|
Der Public Key-Workflow:
|
|
|
|
|
|
Wenn der Tokentyp:
|
|
|
Erforderlich, wenn der Tokentyp Beispiel:
|
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>"
}