Verwenden von VMware Cloud Director als Proxy-Server des Identitätsanbieters

Ab Version 10.4.2 können Sie VMware Cloud Director als mandantenfähigen Identitätsanbieter-Proxyserver verwenden.

Wenn VMware Cloud Director mithilfe des OAuth 2.0 OpenID Connect-Standards als Identitätsanbieter-Proxyserver konfiguriert wird, können vertrauende Seiten VMware Cloud Director für mandantenfähige Authentifizierung von Benutzern verwenden, die in VMware Cloud Director bekannt sind. Weitere Informationen zum OpenID Connect-Standard finden Sie unter OpenID Connect Core 1.0.

Als Identitätsanbieter-Proxyserver übernimmt VMware Cloud Director die Funktion eines Vermittlers zwischen der Clientanwendung (vertrauende Seite) und dem Identitätsanbieter und delegiert die tatsächliche Authentifizierung an den jeweiligen Authentifizierungsmechanismus, der vom Anbieter oder den Mandanten verwendet wird.

Ein Systemadministrator kann vertrauende Seiten konfigurieren, die in VMware Cloud Director integriert werden, und anschließend einzelnen Mandanten erlauben, ihren Benutzern die Verwendung von VMware Cloud Director als Identitätsanbieter-Proxy zu ermöglichen.

Ablauf der Authentifizierung

Die Integration mit VMware Cloud Director wird über den OAuth 2.0-OIDC-Autorisierungscode-Flow-Standard implementiert. Detaillierte Informationen finden Sie unter Authentifizierung mithilfe des Autorisierungscode-Flows.

Wenn beim Umleiten eines Benutzers an VMware Cloud Director durch die vertrauende Seite keine Clientsitzung vorhanden ist, wird der Benutzer zur Anmeldung bei VMware Cloud Director aufgefordert, indem er zuerst die Organisation oder das Anbieterportal für die Anmeldung angibt. Der Benutzer authentifiziert sich über den konfigurierten Authentifizierungsmechanismus, der weitere Umleitungen an externe Identitätsanbieter beinhalten kann. Wenn im Browser des Benutzers eine vorhandene VMware Cloud Director-Benutzersitzung erkannt wird, stellt der Authentifizierungsablauf ein SSO-Erlebnis bereit. Eine Benutzerinteraktion für eine erneute Authentifizierung ist dann nicht mehr erforderlich. Nach erfolgreichem Abschluss des Vorgangs gibt VMware Cloud Director ein Zugriffs- und ID-Token zurück. Der als Teil des Flows ausgegebene Autorisierungscode ist 5 Minuten gültig. Das Zugriffstoken ist 5 Minuten und das ID-Token eine Stunde gültig.

Hinweis:

VMware Cloud Director gibt kein Aktualisierungstoken zurück.

Sie können das Zugriffstoken, das bei erfolgreicher Authentifizierung von VMware Cloud Director zurückgegeben wird, nicht für den Zugriff auf die Benutzeroberflächenportale oder für regelmäßige VMware Cloud Director-API-Aufrufe verwenden.

Details des ID-Tokens

Das von VMware Cloud Director zurückgegebene ID-Token enthält die folgenden OpenID-Standardbeanspruchungen sowie bestimmte VMware Cloud Director-Beanspruchungen.

Beanspruchung	Beschreibung
`at_hash`	(OpenID-Standardbeanspruchung) Hash-Wert des Zugriffstokens.
`sub`	(OpenID-Standardbeanspruchung) Die `userId` in VMware Cloud Director im UUID-Format.
`iss`	(OpenID-Standardbeanspruchung) Öffentliche Adresse von VMware Cloud Director.
`preferred_username`	(OpenID-Standardbeanspruchung) Benutzername des Benutzers in VMware Cloud Director
`nonce`	(OpenID-Standardbeanspruchung) Zeichenfolgenwert, der zum Verknüpfen einer Clientsitzung mit einem ID-Token und zum Abschwächen von Replay-Angriffen verwendet wird. Nur vorhanden, wenn er anfänglich in der Anforderung der vertrauenden Seite enthalten war.
`aud`	(OpenID-Standardbeanspruchung) Die Zielgruppe für dieses Token. Bei diesem Wert handelt es sich um die Client-ID der anfordernden vertrauenden Seite.
`azp`	(OpenID-Standardbeanspruchung) Autorisierte Seite für das Token. Bei diesem Wert handelt es sich um die Client-ID der vertrauenden Seite. Der Wert entspricht der Beanspruchung `aud`.
`name`	(OpenID-Standardbeanspruchung) Vollständiger Name des Benutzers, sofern in VMware Cloud Director bekannt.
`phone_number`	(OpenID-Standardbeanspruchung) Telefonnummer des Benutzers, sofern in VMware Cloud Director bekannt.
`exp`	(OpenID-Standardbeanspruchung) Ablaufzeit. Zeitraum, nach dessen Ablauf das ID-Token nicht für die Verarbeitung akzeptiert wird.
`iat`	(OpenID-Standardbeanspruchung) Zeitpunkt, zu dem das ID-Token ausgestellt wurde.
`email`	(OpenID-Standardbeanspruchung) E-Mail-Adresse des Benutzers, sofern in VMware Cloud Director bekannt.
`roles`	(Benutzerdefinierte VMware Cloud Director-Beanspruchung) Ein Array mit den Namen der Rollen, über die der Benutzer in VMware Cloud Director verfügt.
`groups`	(Benutzerdefinierte VMware Cloud Director-Beanspruchung) Ein Array mit den Namen der Gruppen, zu denen der Benutzer in VMware Cloud Director gehört.
`org_name`	(Benutzerdefinierte VMware Cloud Director-Beanspruchung) Name der Organisation, bei der der Benutzer angemeldet ist.
`org_display_name`	(Benutzerdefinierte VMware Cloud Director-Beanspruchung) Anzeigename der Organisation.
`org_id`	(Benutzerdefinierte VMware Cloud Director-Beanspruchung) Die Organisations-ID im UUID-Format.

Geltungsbereiche von OpenID-Anforderungen

Der Geltungsbereich der OpenID-Anforderung wird verwendet, um die für ein Zugriffstoken geforderten Berechtigungen anzugeben.

Werte der Geltungsbereiche	Beschreibung.
`openid`	Diese Angabe ist erforderlich. OpenID-Standardgeltungsbereich.
`profile`	OpenID-Standardgeltungsbereich. Fordert Zugriff auf die Standardprofilbeanspruchungen des Endbenutzers.
`email`	OpenID-Standardgeltungsbereich. Fordert Zugriff auf die E-Mail-Adressbeanspruchungen des Endbenutzers.
`groups`	OpenID-Standardgeltungsbereich. Fordert Zugriff auf die Gruppen, denen der Benutzer in VMware Cloud Director angehört.
`phone`	OpenID-Standardgeltungsbereich. Fordert Zugriff auf die Telefonnummerbeanspruchungen des Benutzers.
`vcd_idp`	Spezieller VMware Cloud Director-Geltungsbereich. Fordert Zugriff auf benutzerdefinierte VMware Cloud Director-Beanspruchungen, wie z. B. `roles`, `groups`, `org_name`, `org_display_name` und `org_id`.

Endpoints

Sie können das von VMware Cloud Director zurückgegebene Zugriffstoken verwenden, um Beanspruchungen über den authentifizierten Benutzer im Endpoint hostname /oidc/UserInfo abzurufen. Weitere Informationen finden Sie unter UserInfo-Endpoint.
Sie können die Werte für die Anbieterkonfiguration, einschließlich des JWKS-Endpoints und Informationen zu anderen für die OIDC-Proxy-Konfiguration erforderlichen Endpoints und Geltungsbereichen, unter der bekannten Konfigurations-URL hostname/oidc/.well-known/openid-configuration abrufen. Weitere Informationen finden Sie unter Anzeigen der allgemeinen Einstellungen des OIDC-Proxys in VMware Cloud Director.

Zugriff auf VMware Cloud Director-Identitätsanbieter-Proxy zum Tokenaustausch

Die programmgesteuerte Integration mit der Identitätsanbieter-Proxy-Funktion von VMware Cloud Director ist über den Tokenaustausch-Flow verfügbar, der im Folgenden detailliert beschrieben wird. Dieser Flow beinhaltet nicht die VMware Cloud Director-Benutzeroberfläche und eignet sich für skriptbasierten Zugriff, wie z. B. CLI.

Rufen Sie ein VMware Cloud Director-JWT ab, indem Sie sich entweder direkt anmelden oder ein API-Token verwenden.

Führen Sie eine POST-Anfrage aus.

POST  hostname/oidc/oauth2/token

Wählen Sie x-www-form-urlencoded für den Textkörper der Anforderung aus.

Schließen Sie die folgenden Parameter in den Textkörper der Anforderung ein.

{
     "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
     "assertion": "VMware_Cloud_Director JWT",
     "client_id": "Relying_party_ID",
     "scope": "openid profile email phone groups vcd_idp",
   }

In der Antwort wird sowohl ein ID-Token mit den OIDC- und VMware Cloud Director-Beanspruchungen als auch ein Zugriffstoken zurückgegeben, das Sie zum Abrufen von Beanspruchungen über den authentifizierten Benutzer im Endpoint hostname /oidc/UserInfo verwenden können.

Beispiel für ein codiertes ID-Token:

eyJhbGciOiJSUzI1NiIsInR5NDg4SI6I................4dHnbU1RQ6Y9Yohgw

Beispiel für ein decodiertes ID-Token:

{
  "at_hash": "1AA1aAA1AAAAAAaAA1A11a",
  "sub": "111111111-1111-1111-1111-11111111",
  "roles": [
    "Organization Administrator"
  ],
  "iss": "https://hostname/oidc",
  "groups": [
    "ALL USERS"
  ],
  "preferred_username": "testuser@vcd-ms1",
  "nonce": "ab123acab",
  "aud": "33333333-3333-3333-3333-33333333333",
  "azp": "22222222-2222-2222-2222-22222222",
  "org_id": "12345678-1234-1234-1234-123456789abc",
  "org_display_name": "oidcorg",
  "name": "test user",
  "phone_number": " ",
  "exp": 1111111111,
  "org_name": "oidcorg",
  "iat": 1111111111,
  "email": "[email protected]"
}

Beispiel für eine Benutzerinformationsantwort:

{
    "sub": "111111111-1111-1111-1111-11111111",
    "preferred_username": "administrator",
    "name": "administrator user",
    "email": "[email protected]",
    "phone_number": "0 (111) 222-3333",
    "roles": [ "system administrator" ],
    "groups": [],
    "org_name": "system",
    "org_display_name": "System Organization",
    "org_id": "12345678-1234-1234-1234-123456789abc"
}

Überlegungen zu mehreren Standorten

In einer Bereitstellung für mehrere Standorte fungiert jede Site als einzelner Identitätsanbieterserver.

Gekoppelte Sites bieten keine Unterstützung für Verbundidentitätsserver. Somit schlägt die Anmeldung fehl, wenn ein Mandant, der nicht zu der als Identitätsanbieter-Proxy fungierenden Site gehört, während des Anmeldevorgangs versucht, sich bei der Site anzumelden, indem er die Organisationsauswahl einer anderen Site der Bereitstellung für mehrere Standorte verwendet.