Background-App braucht Zugriff? Managed Identity verwenden

Veröffentlicht am:
#entra id

Dieser Trip baut auf folgendem Thema auf:

Client Credentials Flow mit App Registrations (D365 zu Middleware API)

Jetzt ersetzen wir die Authentifizierung des Callers durch:

Managed Identity, ohne Client Secret und ohne caller-seitige App Registration.

Architektur

D365 -> Azure Function (Managed Identity) -> Middleware API

Die Azure Function wird zur vertrauenswürdigen Runtime-Komponente. Sie verwendet ihre Managed Identity, um ein Token für die Middleware API anzufordern.

User Assigned Managed Identity erstellen

Gehe zu:

Azure Portal > Managed Identities > Create

Erstelle die Identität:

Type: User Assigned Managed Identity
Name: mi-d365-function-integration

Azure Portal-Seite zum Erstellen einer User Assigned Managed Identity

Managed Identity der Azure Function zuweisen

Öffne die Function App und gehe zu:

Function App > Identity > User assigned > Add

Füge hinzu:

mi-d365-function-integration

Die Function App kann sich jetzt als diese Managed Identity authentifizieren.

Azure Function Identity-Blade mit zugewiesener User Assigned Managed Identity

Identity-Konzept

Es gibt drei verwandte Identity-Objekte, die leicht verwechselt werden.

App Registration Object ID

  • Definitionsebene
  • speichert Anwendungskonfiguration
  • wird für OAuth-Setup verwendet
  • nicht für Runtime-Zugriffszuweisungen verwendet

Enterprise Application Object ID

  • Runtime-Identität im Tenant
  • wird auch Service Principal genannt
  • repräsentiert die tatsächliche Identität, die Berechtigungen erhält
  • wird für Autorisierung verwendet

Managed Identity Object ID

  • automatisch erstellter Service Principal
  • repräsentiert die Identität der Azure-Ressource
  • wird für Authentifizierung und Microsoft Graph-Operationen verwendet

Wichtige Regel:

Nur Service Principal Object IDs werden in Graph API Calls und App Role Assignments verwendet

App Role der Managed Identity zuweisen

Das ist der zentrale Schritt.

Die Middleware API stellt bereits eine App Role bereit, zum Beispiel:

middleware.access

Jetzt weisen wir diese Rolle der Managed Identity zu.

Verwende Microsoft Graph über Azure CLI:

az rest --method POST \
  --uri "https://graph.microsoft.com/v1.0/servicePrincipals/<MI_OBJECT_ID>/appRoleAssignments" \
  --body '{
    "principalId": "<MI_OBJECT_ID>",
    "resourceId": "<MIDDLEWARE_API_SP_OBJECT_ID>",
    "appRoleId": "<Middleware.Access_ROLE_ID>"
  }'

Bedeutung der Werte

Feld Bedeutung
principalId Service Principal Object ID der Managed Identity, also der Caller
resourceId Service Principal Object ID der Middleware API, also die Ziel-API
appRoleId App Role ID für Middleware.Access

Azure- oder Microsoft Entra-Ansicht mit dem principalId-Wert der Managed Identity

Azure- oder Microsoft Entra-Ansicht mit dem resourceId-Wert der Middleware API

Microsoft Entra App Role-Ansicht mit dem appRoleId-Wert

Wichtige Klarstellung

In Entra ID gibt es mehrere Object IDs.

Die App Registration Object ID definiert die Konfiguration.

Die Enterprise Application Object ID ist der Service Principal, der für Runtime-Autorisierung verwendet wird.

Die Managed Identity Object ID ist ebenfalls ein Service Principal. Dieses Objekt verwenden wir als Caller im POST Request oben.

Daher gilt:

Managed Identity Object ID = Service Principal Object ID

Runtime-Verhalten

Wenn die Azure Function ausgeführt wird:

  • Managed Identity fordert automatisch ein Token an
  • Entra ID stellt ein Access Token aus
  • Token enthält die zugewiesene App Role
  • Middleware API validiert Audience und Rolle
Managed Identity -> Entra ID -> Access Token -> Middleware API

Vergleich

Ansatz Secrets Caller App Registration Sicherheit
Client Credentials Ja Erforderlich Mittel
Managed Identity Nein Nicht nötig Hoch