OAuth-Anwendungen

Eine OAuth-Anwendung speichert Anmeldedaten und Token zur Authentifizierung gegenüber einem Webdienst. OAuth 2.0 ist ein Protokoll gemäß Industriestandard für die Autorisierung. Weitere Informationen finden Sie unter https://oauth.net/2/.

Eine OAuth-Anwendung erstellen

  1. Wählen Sie das Symbol Glühbirne, die die Tell Me Funktion öffnet, geben Sie OAuth-Anwendungen - Task-Based Scheduling ein und wählen Sie dann den entsprechenden Link.
  2. Wählen Sie die Aktion Neu aus.
  3. Füllen Sie auf der Seite OAuth-Anwendungskarte die erforderlichen Felder aus. Fahren Sie über ein Feld, um eine Kurzbeschreibung zu lesen.

Eine App für eine Business Central-Webdienstverbindung registrieren

Gehen Sie folgendermaßen vor, um eine Anwendung zu erstellen, die eine Verbindung von einer OAuth-Anwendung in COSMO Taktorientierte Planung herstellt.

  1. Registrieren Sie eine App im Azure-Portal. Fügen Sie für die Verbindung zu Business Central den Endpunkt OAuthLanding.htm hinzu (zum Beispiel https://businesscentral.dynamics.com/[<Umgebungs-ID>/]OAuthLanding.htm). Sie können den Kontotyp auf Multitenant setzen, wenn die App über verschiedene Azure-Tenants geteilt wird.

  2. Für eine Service-to-Service (S2S)-Authentifizierung erstellen Sie Anwendungsberechtigungen für Dynamics 365 Business Central und aktivieren Sie API.ReadWrite.All. Sie können auch delegierte Berechtigungen verwenden und user_impersonation und Financial.ReadWrite.All überprüfen, wenn ein bestimmter Benutzer für die Authentifizierung verwendet werden soll.

  3. Erstellen Sie ein Clientgeheimnis und kopieren Sie den Wert für die nächsten Schritte.

  4. Suchen Sie die Client-ID und die Azure-Endpunkte. Kopieren Sie die Werte für die nächsten Schritte. Die Endpunktversion definiert die verwendeten OAuth-Parameter, wie z. B. scope und resource. Für die Service-to-Service (S2S)-Authentifizierung auf der Grundlage des Grant-Typs Client Credentials benötigen Sie nur den OAuth 2.0 Token-Endpunkt (v2). Für andere Genehmigungsverfahren benötigen Sie möglicherweise auch den OAuth 2.0 authorization endpoint (v2).

  5. Erteilen Sie mit Administratorrechten die Genehmigung für die registrierte App (API permissions > Grant admin consent for <Firmenname> erteilen). Sie können die Berechtigungen auch von Business Central aus erteilen, was jedoch aufgrund möglicher Authentifizierungsfehler nicht empfohlen wird.

Die Anwendungsberechtigungen in Business Central festlegen

Für die Service-to-Service (S2S)-Authentifizierung müssen für die zuvor erstellte App in Business Central Berechtigungen definiert werden.

  1. Wählen Sie das Symbol Glühbirne, die die Tell Me Funktion öffnet, geben Sie Azure Active Directory-Anwendungen ein, und wählen Sie dann den entsprechenden Link.

  2. Geben Sie die Client-ID aus den vorherigen Schritten und eine Beschreibung ein. Die Beschreibung wird als Benutzername verwendet. Wählen Sie Status = Aktiviert und bestätigen Sie den Dialog. Wählen Sie dann Zustimmung erteilen und bestätigen Sie den nächsten Dialog. Wenn der Azure-App nicht bereits im Azure-Portal die Zustimmung erteilt wurde, kann ein weiterer Dialog erscheinen. Die Azure-App wird nun durch einen neuen Benutzer in Business Central repräsentiert.

  3. Blättern Sie auf der Seite Azure Active Directory-Anwendungen nach unten und legen Sie die gewünschten Berechtigungen für die Azure-App fest. Der Berechtigungssatz SUPER darf nicht verwendet werden. In diesem Beispiel verwenden wir die Benutzergruppe D365 FULL ACCESS mit genügend Berechtigungen, um Daten in das Data Integration Framework zu übertragen.

Eine OAuth-Anwendung zur Verbindung mit Business Central erstellen

Erstellen Sie eine OAuth-Anwendung im Absendermandanten, um sich beim Zielmandanten zu authentifizieren. Die Werte basieren auf einer SaaS-Zielumgebung.

  1. Gehen Sie zu Business Central und erstellen Sie eine neue OAuth-Anwendung. Geben Sie einen Code, eine Beschreibung und wählen Sie Art = OAuth 2.0 aus.
  2. Wählen Sie die Aktion Initialisieren für Business Central (SaaS), um einige der Werte auf der Grundlage der aktuellen Umgebung zu initialisieren.
  3. Geben Sie die Werte aus den vorherigen Schritten in die Felder Client ID, Client Secret und Access Token URL ein. Für andere Authentifizierungsarten als Service-to-Service sind zusätzliche Werte erforderlich.
  4. Das Feld Bereich muss https://api.businesscentral.dynamics.com/.default lauten, um Business Central anzusprechen.
  5. Das Feld Genehmigungsverfahren muss Client-Anmeldeinformationen für die Service-to-Service-Authentifizierung lauten.
  6. Wählen Sie die Aktion Anforderung Zugriffstoken, um die Authentifizierung zu testen. Entsprechend dem Feld Genehmigungsverfahren wird möglicherweise ein Dialogfeld mit der Aufforderung angezeigt, sich mit den Anmeldedaten des Benutzers anzumelden. Der Status sollte Verbunden sein.
  7. Optional: Wählen Sie die Aktion Token löschen, um die zwischengespeicherten Token zu entfernen. Wenn Sie das Token nicht löschen, wird beim nächsten Authentifizierungsversuch das Aktualisierungs-Token verwendet, um ein neues Zugriffstoken zu erstellen, ähnlich wie bei der Aktion Zugriffstoken aktualisieren.

Business Central Connected

Tip

Wählen Sie die Aktion Initialisieren für Business Central (SaaS), um einige der Werte auf der Grundlage der aktuellen Umgebung zu initialisieren. Beachten Sie jedoch, dass es sich hierbei nur um die Werte für den sendenden Mandanten handelt. Wählen Sie die Aktion auf dem Zielmandanten und kopieren Sie die Werte bzw. ändern Sie sie.

Tip

Für v1-Endpunkte muss das Feld Ressource https://api.businesscentral.dynamics.com sein.

Tip

Wenn Sie andere Genehmigungsverfahren als Client-Anmeldeinformationen wählen, müssen die Felder Benutzername, Passwort oder Weiterleitungs-URL entsprechend dem Typ gesetzt werden.

Tip

In Sandbox-Umgebungen kann die Aktion Aktuellen Token anzeigen verwendet werden, um die Audience und den Scope des empfangenen Tokens zu überprüfen. Verwenden Sie zum Beispiel https://jwt.io/, um das Token zu entschlüsseln und detaillierte Informationen zu finden.

Client-Anmeldeinformationen

Wenn Sie Genehmigungsverfahren = Clientanmeldeinformationen wählen, werden nur die Client-ID, Clientgeheimnis, Bereich und Ressource zur Authentifizierung verwendet. Dieser Typ ist die beste Vorgehensweise für eine einfache Service-to-Service-Verbindung mit Business Central in SaaS.

Passwort Anmeldeinformationen

Wenn Sie Genehmigungsverfahren = Passwort Anmeldeinformationen wählen, müssen Sie die Felder Benutzername und Kennwort des Benutzers festlegen, der für die Authentifizierung im Zielmandanten verwendet werden soll. Dies ist in der Regel ein Dienstbenutzer. Der Fluss der Passwort Anmeldeinformationen öffnet nicht jedes Mal einen Zustimmungsdialog. Sie kann für die benutzerbasierte Authentifizierung verwendet werden.

Autorisierungscode

Für das Genehmigungsverfahren = Autorisierungscode müssen Sie das Feld Weiterleitungs-URL setzen.

Der Autorisierungscodefluss kann einen Zustimmungsdialog öffnen, in dem sich der Benutzer mit seinen Anmeldedaten anmelden muss. UI-Dialoge sind für Hintergrund- oder automatisierte Aufgaben nicht zulässig. Diese Option sollte verwendet werden, wenn die Ausführung der Partnerzuordnung eine benutzerdelegierte Berechtigung im Zielmandanten erfordert.

Implizit

Das Genehmigungsverfahren = Implizit erfordert die Client-ID, aber kein Clientgeheimnis. Außerdem kann das Feld Zugriffstoken-URL übersprungen werden, da das Token direkt von der Autorisierungs-URL über einen Zustimmungsdialog abgerufen wird. UI-Dialoge sind für Hintergrund- oder automatisierte Aufgaben nicht zulässig. Das Feld Weiterleitungs-URL muss konfiguriert werden.

Diese Option sollte verwendet werden, wenn die Ausführung vom Partner Mapping bei jeder Ausführung eine neue Anmeldung erfordert. Der implizite Fluss hat kein Aktualisierungstoken und erfordert eine Anmeldung für jede Anfrage.

Weiterleitungs-URL

Business Central bietet einen festen Endpunkt für die Verarbeitung von OAuth-Rückrufen. Dieser Endpunkt muss sowohl in der Weiterleitungs-URL der OAuth-Anwendung als auch in der registrierten App im Azure-Portal korrekt angegeben werden. Die URL ist definiert als https://<Servername>[:<Port>]/[<aad tenant id>/][<Umgebungsname>/]OAuthLanding.htm. Ein Beispiel für eine SaaS-Umgebung ist https://businesscentral.dynamics.com/e1894b46-5483-4e16-a0c6-0d039b12b488/Production/OAuthLanding.htm.

Note

Die Verwendung des http-Protokolls für lokale Umgebungen kann schwierig sein, da das Azure-Portal nur http://localhost für unsichere Verbindungen zulässt. Um sich von einem lokalen Docker-Container aus zu verbinden, verwenden Sie einen IIS und leiten Sie die http://localhost:<Ihr-Port>-Aufrufe durch die Einstellung <httpRedirect enabled="true" destination="http://<Ihr Docker-Container>/bc/OAuthLanding.htm$Q" /> in Ihrer web.config auf Ihren Docker-Container um.


Feedback

Senden Sie Feedback für diese Seite . (Beachten Sie, dass diese Umfrage auf Englisch ist.)