Protokoll zur Identitätsübernahme des Benutzerkontos des Agents

Die Identitätsübernahme des Benutzerkontos eines Agenten ermöglicht es, im Rahmen der Identität des Agenten mit dem Benutzerkontext des Agenten zu arbeiten, wodurch Benutzerberechtigungen mit autonomem Betrieb kombiniert werden. In diesem Szenario gibt sich eine Agentenidentitätsblaupause (Akteur 1) unter Verwendung von FIC als eine Agentenidentität (Akteur 2) aus, die ihrerseits das Benutzerkonto eines Agenten (Subjekt) imitiert. Der Zugriff ist auf Delegierungen beschränkt, die der Agentenidentität zugewiesen sind. Das Benutzerkonto des Agents kann nur durch eine einzelne Agentidentität imitiert werden.

Warnung

Microsoft empfiehlt die Verwendung der genehmigten SDKs wie Microsoft. Identity.Web- und Microsoft Entra ID Auth SDK-Bibliotheken (Sidecar) zum Implementieren dieser Protokolle. Die manuelle Implementierung dieser Protokolle ist komplex und fehleranfällig, und die Verwendung der SDKs trägt dazu bei, Sicherheit und Compliance mit bewährten Methoden sicherzustellen.

Integration verwalteter Identitäten

Verwaltete Identitäten sind der bevorzugte Anmeldedatentyp. In dieser Konfiguration dient das verwaltete Identitätstoken als Anmeldeinformation für die Identitätsvorlage des übergeordneten Agents, während standardmäßige MSI-Protokolle für den Erwerb von Anmeldeinformationen gelten. Diese Integration ermöglicht es der Agent-ID, um die umfassenden Vorteile der MSI-Sicherheit und -Verwaltung zu nutzen, einschließlich der automatischen Rotation von Anmeldeinformationen und der sicheren Speicherung.

Protokollschritte

Dann folgen die Protokollschritte.

Diagramm, das den Ablauf der Token-Erwerbung für Benutzerkonten von Agenten zeigt.

  1. Der Agentenidentitäts-Blueprint fordert ein Exchange-Token (T1) an, das es für die Identitätsimitation des Agenten verwendet. Der Agentenidentitäts-Blueprint präsentiert Client-Anmeldeinformationen, die ein Geheimnis, ein Zertifikat oder ein verwaltetes Identitätstoken sein können, das als FIC verwendet wird.

    Warnung

    Geheime Clientschlüssel dürfen in Produktionsumgebungen aufgrund von Sicherheitsrisiken nicht als Clientanmeldeinformationen für Agent-Identitätsblaupausen verwendet werden. Verwenden Sie stattdessen sicherere Authentifizierungsmethoden wie Verbundidentitätsanmeldeinformationen (FIC) mit verwalteten Identitäten oder Clientzertifikaten. Diese Methoden bieten eine verbesserte Sicherheit, da vertrauliche geheime Schlüssel nicht direkt in Ihrer Anwendungskonfiguration gespeichert werden müssen.

    POST /oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id=AgentBlueprint
&scope=api://AzureADTokenExchange/.default
&fmi_path=AgentIdentity
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=TUAMI
&grant_type=client_credentials

    Dabei ist TUAMI das MSI-Token für vom Benutzer zugewiesene verwaltete Identität (UAMI). Dadurch wird das Token T1 zurückgegeben.

  2. Die Agentenidentität stellt eine Anforderung an ein Token (T2) auf, das sie für die Identitätsübernahme des Benutzerkontos des Agenten verwendet. Die Agentenidentität gibt T1 als Client-Assertion aus. Microsoft Entra ID gibt T2 als Identität des Agenten zurück, nachdem überprüft wurde, dass T1 (aud) == übergeordnete App der Agentenidentität == Blaupause der Agentenidentität gilt.​

    POST /oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id=AgentIdentity
&scope=api://AzureADTokenExchange/.default
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion={T1}
&grant_type=client_credentials

    Dadurch wird das Token T2 zurückgegeben.

  3. Die Identität des Agenten sendet dann eine OBO-Tokenaustauschanforderung an Microsoft Entra ID, einschließlich T1 und T2. Microsoft Entra ID validiert, dass T2 (aud) == Agentenidentität.

    POST /oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id=AgentIdentity
&scope=https://resource.example.com/scope1
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion={T1}
&user_federated_identity_credential={T2}
&username=agentuser@contoso.com
&grant_type=user_fic
&requested_token_use=on_behalf_of

  4. Microsoft Entra ID gibt dann das Ressourcentoken aus.

Sequenzdiagramm

Das folgende Sequenzdiagramm zeigt den Impersonationsfluss des Benutzerkontos des Agents.

Diagramm, das die Tokensequenz im Token-Akquisitionsprozess für Benutzerkonten von Agenten zeigt.

Wenn ein Agent das Benutzerkonto übernimmt, erfordert dies eine Verkettung von Anmeldeinformationen, die dem Muster: Agentidentitäts-Blaupause → Agentidentität → Benutzerkonto folgt. Jeder Schritt in dieser Kette verwendet das Token aus dem vorherigen Schritt als Berechtigungsnachweis, um einen sicheren Delegierungspfad zu schaffen. Die gleiche Client-ID muss für beide Phasen verwendet werden, um Berechtigungseskalationsangriffe zu verhindern.

  • Last updated on