Freigeben über

Agent-Benutzer-Imitationsprotokoll

Die Agentenbenutzer-Impersonation ermöglicht es Agentenidentitäten, im Benutzerkontext über Agentenbenutzer zu agieren und Benutzerberechtigungen mit autonomem Betrieb zu kombinieren. In diesem Szenario imitiert ein Identitätsentwurf für Agenten (Akteur 1) eine Agentenidentität (Akteur 2), die wiederum einen Agentennutzer (Subjekt) mithilfe von FIC imitiert. Der Zugriff ist auf Delegierungen beschränkt, die der Agentenidentität zugewiesen sind. Der Agentbenutzer kann nur durch eine einzelne Agentidentität imitiert werden.

Warnung

Microsoft empfiehlt die Verwendung der genehmigten SDKs wie Microsoft.Identity.Web- und Microsoft Agent ID SDK-Bibliotheken, um diese Protokolle zu implementieren. 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 Standard-MSI-Protokolle für den Erhalt der Anmeldeinformation gelten. Diese Integration ermöglicht es der Agent-ID, den vollständigen Nutzen der MSI-Sicherheit und -Verwaltung voll auszuschöpfen, einschließlich der automatischen Drehung der Zugangsdaten und der sicheren Speicherung.

Protokollschritte

Dann folgen die Protokollschritte.

Diagramm mit der Abbildung des Agent-Benutzertokenakquisitionsflusses für Agents.

  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 sollten aufgrund von Sicherheitsrisiken nicht als Clientanmeldeinformationen in Produktionsumgebungen für Agentidentitäts-Blueprints 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 Agentidentität fordert ein Token (T2) an, das sie für die Nachahmung des Agentbenutzers verwendet. Die Agentenidentität gibt T1 als Client-Assertion aus. Microsoft Entra ID gibt T2 an die Agentenidentität zurück, nachdem geprüft wurde, ob T1 (aud) == übergeordnete Agentenidentitäts-App == Agentenidentitäts-Blueprint ist.

    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 Agentidentität sendet dann eine OBO-Token-Austauschanforderung an Microsoft Entra ID, einschließlich T1 und T2. Die Microsoft Entra-ID stellt sicher, dass T2 (aud) == Agentenidentität ist.

    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}
&assertion={T2}
&username=agentuser@contoso.com
&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&requested_token_use=on_behalf_of

  4. Microsoft Entra ID gibt dann das Ressourcentoken aus.

Sequenzdiagramm

Das folgende Sequenzdiagramm zeigt den Impersonierungsfluss des Agent-Nutzers.

Diagramm mit der Tokensequenz des Agent-Benutzertokenakquisitionsflusses für Agents.

Der Identitätswechsel des Agentbenutzers erfordert die Verkettung von Anmeldeinformationen, die dem Muster-Agent-Identitäts-Blueprint → Agent-Identität → Agent-Benutzer 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