Authentifizierung mit Microsoft Entra Auth SDK (Sidecar)

Das Microsoft Entra Auth SDK (Sidecar)- verarbeitet Authentifizierungs- und Tokenvorgänge für Ihren KI-Agent. Es läuft als zweiter Container neben Ihrem Agenten, der den Austausch von Client-Anmeldeinformationen, On-Behalf-of-Fluss und die Token-Lebenszyklusverwaltung übernimmt. In diesem Artikel wird das Entwurfsmuster Microsoft Entra Auth SDK (Sidecar) erläutert, wie es funktioniert, und die beteiligten Identitätsobjekte.

Warum sollte man den Microsoft Entra SDK-Auth Sidecar verwenden?

KI-Agents benötigen Anmeldeinformationen, um nachgeschaltete APIs aufzurufen, aber die gängigen Ansätze für die Agentauthentifizierung reichen nicht aus.

  • Hartcodierte Geheimnisse im Agentcode: Jedes Agent-Image enthält eine Kopie der Daten Ihrer Appclient_secret. Alle Kompromittierungen, Protokolllecks oder vergessene .env-Dateien, die an Git gebunden sind, machen den vollständigen Mandanten verfügbar.
  • Delegierte Benutzertoken für alles: Der Agent kann nur handeln, wenn ein Mensch anwesend ist. Außerdem verlieren Sie die individuelle Auditierbarkeit, da jeder Aufruf den Anschein erweckt, vom selben Dienstprinzipal zu stammen.

Microsoft Entra-Agent-ID gibt jedem Agent seine eigene Identität. Das Sidecar-Muster vereinfacht die Verwendung dieser Identität, indem die gesamte Anmeldeinformationsverwaltung außerhalb des Agentencodes erfolgt.

Funktionsweise des Microsoft Entra SDK-Auth-Sidecars

Der Microsoft Entra SDK Auth Sidecar wird als Container ausgeführt, der HTTP-Endpunkte im pod-lokalen Netzwerk verfügbar macht. Es übernimmt die folgenden Verantwortlichkeiten:

  • Tauscht Clientanmeldeinformationen mit login.microsoftonline.com.
  • Erwirbt Tokens über Client-Anmeldeinformationen oder föderierte Identitäts-Anmeldeinformationen (FIC) für die Agentenidentität in autonomen Abläufen.
  • Behandelt OBO-Vorgänge für Benutzerkontext-Aufrufe.
  • Cacht Token und verwaltet Aktualisierung und Verfall.
  • Abstrahiert die Anmeldeinformationsquelle – verwendet ClientSecret für die Entwicklung und SignedAssertionFromManagedIdentity für Azure Bereitstellungen über dieselbe API.

In der folgenden Tabelle wird der Ablauf von Authentifizierungsaktionen zwischen Ihrem Agent und dem Sidecar zusammengefasst:

Agent (Ihr Code) Sidecar (Microsoft Entra SDK)
Entscheiden, wann die API aufgerufen werden soll Abrufen und Zwischenspeichern des richtigen Tokens
Erstellen der HTTP-Anforderung Ausführen von Clientanmeldeinformationen und OBO-Austausch
Benutzertoken für OBO übergeben Überprüfung und Weiterleitung der Benutzeraussage
Bearbeitung der Geschäftslogik Kommunikation mit login.microsoftonline.com

Die Sicherheitsgrenze ist explizit: Der Sidecar hat keinen Host-Port. Nur Dienste innerhalb desselben Netzwerks, z. B. Ihr Agentcontainer, können Token anfordern.

Identitätsobjekte im Sidecar-Muster

In der folgenden Tabelle werden die Microsoft Entra Objekte im Seitenwagenmuster beschrieben:

Objekt Rolle Speicherort
Blueprint-Anwendung Vorlage, die Agentidentitäten erstellt und ausgibt. Enthält die Clientanmeldeinformationen (geheimer Schlüssel oder föderiert). Ihr Microsoft Entra-Mandant
Agentidentität Der einzelne KI-Agent. Verfügt über eine eindeutige App-ID, Berechtigungen und einen Prüfpfad. Ihr Microsoft Entra-Mandant
Client SPA (nur OBO) Web-UI, die den Benutzer anmeldet und das Token des Benutzers für ein Agenttoken in seinem Namen austauscht. Ihr Microsoft Entra-Mandant
Sidecar-Container Führt Clientanmeldeinformationen und OBO-Flüsse aus. Besitzt die Blueprint-Zugangsdaten. Neben Ihrem Agenten
Agentcontainer Ihr Anwendungscode. Fordert Autorisierungsheader vom Sidecar an. Ihr Pod, Compose-Dienst oder App-Dienst

Weitere Informationen zu Blueprints und Agentidentitäten finden Sie unter Agent-Identitätsblaupausen und Agentidentitäten.

Abstraktion der Anmeldeinformationen

Der Sidecar abstrahiert die Quelle der Anmeldeinformationen von Ihrem Agentencode. Während der Entwicklung können Sie ein ClientSecret zur Vereinfachung nutzen. Bei produktiven Azure-Bereitstellungen können Sie auf SignedAssertionFromManagedIdentity, eine föderierte Identitäts-Anmeldeinformation, die durch verwaltete Identität unterstützt wird, umstellen, ohne Ihren Agent-Code zu ändern.

Die Konfiguration des Sidecars bestimmt, welche Anmeldeinformationsquelle verwendet werden soll. Ihr Agent ruft unabhängig vom Authentifizierungsmechanismus weiterhin denselben /AuthorizationHeader Endpunkt auf.

Sidecar-Beispielszenarien

Die Microsoft Entra-Agent-ID Sidecar-Beispiele veranschaulichen die folgenden Konzepte:

  • Wie sich ein Blueprint von einer Agentidentität unterscheidet und warum Agenten ihre eigene Identität benötigen.
  • Wie das Sidecar die Endpunkte /AuthorizationHeader (Token abrufen) und /DownstreamApi (Token + Proxy-Aufruf) verfügbar macht.
  • Wie der Sidecar das Token eines angemeldeten Benutzers weiterleitet und das Microsoft Entra SDK über OBO ein Agent-im-Hals-des-Benutzers-Token erzeugt.
  • Wie die downstream-API Agenttoken überprüft, einschließlich Signatur, Aussteller xms_par_app_azpund Zielgruppe.
  • So tauschen Sie zwischen ClientSecret (Entwicklung) und SignedAssertionFromManagedIdentity (Azure Bereitstellungen) aus, ohne den Agentcode zu ändern.

Verwandte Inhalte

  • Last updated on