Integrationsmöglichkeiten mit benutzerdefinierten Konnektoren
Benutzerdefinierte Konnektoren in Power Automate ermöglichen die direkte Integration mit den REST-API-Endpunkten von Dynamics 365 Finance & Supply Chain Management (F&SCM) unter Verwendung von OAuth 2.0 und eröffnen damit erhebliche Möglichkeiten für die Prozessautomatisierung außerhalb der Standardkonnektoren.
Ein praktisches Beispiel ist die Integration der Dokumentenarchivierung mit unserem FlexxStore Dokumentenmanagement-Add-on für Dynamics 365 Finance & SCM. Mit einem benutzerdefinierten Konnektor können Sie die folgenden Prozesse automatisieren:
- Hinzufügen von Dokumenten zu Ihrem Archiv, während sie in Dynamics 365 angezeigt werden
- Scannen von Dokumenten (Rechnungen, Lieferscheine, ...) in Dynamics 365
- Power Apps zum Abfotografieren von Dokumenten und Hinzufügen zum Archiv
- Archivierung von E-Mails und Anhängen durch Weiterleitung an eine überwachte Mailbox
- Automatisierte Weiterleitung von Dokumenten auf der Grundlage von in Power Automate definierten Geschäftsregeln
Dieses Integrationsmuster umgeht die traditionellen Beschränkungen von Standardkonnektoren, indem es direkt mit REST-API-Endpunkten für benutzerdefinierte Dienste kommuniziert, die über das Custom Service Framework von D365 bereitgestellt werden.
OAuth 2.0-Authentifizierung für die D365 F&SCM-Integration
OAuth 2.0 ist das erforderliche Authentifizierungsprotokoll, wenn Sie Power Automate über benutzerdefinierte Konnektoren mit D365 F&SCM verbinden. Es bietet ein sicheres Autorisierungs-Framework, ohne dass Anmeldedaten über Servicegrenzen hinweg offengelegt werden.
Für die D365 F&SCM REST API-Integration sind zwei OAuth 2.0-Grant-Typen am wichtigsten:
Client Credentials
Dieser Grant-Typ ist für die Server-zu-Server-Authentifizierung ohne Benutzerkontext gedacht:
- Ablauf: Die Client-Anwendung fordert direkt ein Zugriffstoken vom Autorisierungsserver an, indem sie ihre Client-Anmeldeinformationen (ID und Geheimnis) vorlegt.
- Authentifizierungsbereich: Nur Berechtigungen auf Anwendungsebene
- Ausgabe von Token: Allein auf der Grundlage der Identität der Anwendung
- Verwendungsszenario: Hintergrundprozesse, geplante Synchronisationen, Integrationen auf Systemebene
Authorization Code
Dieser Grant-Typ ist für die delegierte Benutzerauthentifizierung gedacht:
- Ablauf: Der Benutzer authentifiziert sich, der Autorisierungsserver gibt einen temporären Code aus, die Anwendung tauscht diesen Code gegen ein Zugriffstoken aus.
- Authentifizierungsbereich: Delegierte Berechtigungen, die im Namen des authentifizierten Benutzers handeln
- Ausgabe von Token: Basierend auf der Benutzeridentität mit Zustimmung
- Anwendungsszenario: Interaktive Prozesse, bei denen der Benutzerkontext eine Rolle spielt, vom Benutzer ausgelöste Workflows
Auswirkungen des Grant-Types auf die D365 F&SCM-Autorisierung
Die Auswahl des Grant-Types wirkt sich direkt darauf aus, wie die Autorisierung in D365 F&SCM gehandhabt wird:
Implementierung von Client Credentials
Bei der Implementierung des Client Credentials Flow:
- Eine Entra ID (ehemals Azure AD) Anwendung muss registriert und mit Berechtigungen versehen werden
- Die Anwendung muss explizit in D365 F&SCM registriert werden, um Nicht-Benutzer-Operationen zu autorisieren. Konfiguration in D365:
- Navigieren Sie zu Systemverwaltung > Setup > Microsoft Entra ID Applications
- Registrieren Sie die ID der Anwendung und erteilen Sie die entsprechenden Berechtigungen
- Der Token enthält keine Informationen zur Benutzeridentität, sondern nur Anwendungsansprüche
- Beschränkt auf Vorgänge, die keinen Benutzerkontext erfordern
- Die Operationen werden im Kontext des Benutzers ausgeführt, der der Entra ID Anwednung in D365 F&SCM zugewiesen ist.
Autorisierungscode Implementierung
Bei der Implementierung des Autorisierungscodeflusses:
- Keine explizite Registrierung der Entra ID-Anwendung innerhalb von D365 F&SCM erforderlich
- Die Identität des Benutzers aus dem Token wird für die Autorisierung verwendet
- Der Benutzer muss in D365 F&SCM mit den entsprechenden zugewiesenen Sicherheitsrollen existieren
- Die Operationen werden im Kontext des authentifizierten Benutzers ausgeführt
- Die gesamte Zugriffskontrolle folgt den Standard-D365-Sicherheitsrollenzuweisungen
Herausforderungen in der Power Automate Custom Connector Authentifizierung
Das benutzerdefinierte Connector-Framework von Power Automate stellt besondere Herausforderungen bei der Implementierung von OAuth 2.0 dar:
Intransparenz des Grant-Types
Power Automate gibt während der Konfiguration des Connectors nicht ausdrücklich an, welcher OAuth 2.0 Grant-Typ verwendet wird. Diese Zweideutigkeit kann bei der Implementierung und Fehlerbehebung zu Verwirrung führen.
Token-Analyse
Indem Sie die Token-Nutzdaten untersuchen, die Sie während der Authentifizierung erhalten, können Sie den tatsächlichen Grant-Typ bestimmen:
// Authorization Code grant token (contains user information)
{
"aud": "https://dynamicsinstance.operations.dynamics.com",
"iss": "https://sts.windows.net/tenant-id/",
"iat": 1615983494,
"nbf": 1615983494,
"exp": 1615987394,
"aio": "...",
"amr": ["pwd"],
"appid": "application-id",
"appidacr": "0",
"idp": "https://sts.windows.net/tenant-id/",
"oid": "user-object-id",
"rh": "...",
"sub": "user-subject-id",
"tid": "tenant-id",
"unique_name": "user@domain.com",
"upn": "user@domain.com",
"uti": "...",
"ver": "1.0"
}
Das Vorhandensein von Benutzerkennungen wie upn, unique_name und benutzerspezifischen Ansprüchen weist auf einen Berechtigungscode hin.
Anforderungen zur Authentifizierung
Basierend auf der Token-Analyse implementieren die benutzerdefinierten Konnektoren von Power Automate für D365 F&SCM in der Regel den Grant-Typ Autorisierungscode, was kritische Auswirkungen hat:
- Das beim Verbindungsaufbau verwendete Benutzerkonto muss in D365 F&SCM existieren.
- Dieser Benutzer muss über die entsprechenden Sicherheitsrechte für alle Operationen verfügen, die der Fluss ausführt
- Verbindungsprobleme sind oft auf falsche Benutzerrechte zurückzuführen und nicht auf Probleme bei der Konfiguration des Connectors.
- Die reine Dienstprinzipal-Authentifizierung (ohne Benutzerkontext) wird in den benutzerdefinierten Standardkonfigurationen von Power Automate nicht unterstützt.
Dies schränkt Szenarien ein, in denen Abläufe ohne spezifischen Benutzerkontext funktionieren müssen, was im Wesentlichen ein Dienstkonto mit entsprechenden Berechtigungen in D365 F&SCM erfordert.
Fazit
Bei der Implementierung von Power Automate-Integrationen mit benutzerdefinierten D365 F&SCM-Service-Endpunkten:
- Verstehen Sie, dass OAuth 2.0 Autorisierungscode-Gewährung die Standard-Authentifizierungsmethode ist
- Stellen Sie sicher, dass der verbindende Benutzer sowohl in Entra ID als auch in D365 F&SCM mit den richtigen Berechtigungen existiert.
- Verwenden Sie für Dienst-zu-Dienst-Szenarien ein dediziertes Dienstkonto, anstatt zu versuchen, einen Client Credentials Flow zu implementieren.
- Überwachen Sie den Ablauf von Token und implementieren Sie geeignete Aktualisierungsmechanismen, um die Stabilität der Verbindung aufrechtzuerhalten.
Wenn Sie die Authentifizierung richtig konfigurieren, bieten benutzerdefinierte Konnektoren leistungsstarke Integrationsmöglichkeiten zwischen Power Automate und D365 F&SCM, die über die Möglichkeiten von Standardkonnektoren hinausgehen.
