Verwendung der Office365-Authentifizierung mit Microsoft Dataverse

  • Artikel

Wichtig

Die Verwendung des WS-Trust (Office365)-Authentifizierungssicherheitsprotokolls beim Herstellen einer Verbindung mit Microsoft Dataverse wird nicht mehr empfohlen und ist veraltet; siehe die Bekanntmachung.

Darüber hinaus unterstützt das WS-Trust-Protokoll keine modernen Formen der Multi-Faktor-Authentifizierung und der Microsoft Entra ID-Zugangskontrolle zu Kundendaten.

Dieses Dokument beschreibt die Auswirkungen auf und die erforderlichen Änderungen am Authentifizierungscode für angepasste Client-Anwendungen, die die „Office365“-Authentifizierung und die Klassen OrganizationServiceProxy, ServiceClient oder CrmServiceClient verwenden. Wenn Ihre Anwendungen diese Art von Authentifizierungsprotokoll und API verwenden, lesen Sie weiter unten, um mehr über die empfohlenen Änderungen an der Authentifizierung zu erfahren, die am Code Ihrer Anwendung vorgenommen werden sollten.

Woher weiß ich, ob mein Code oder meine Anwendung WS-Trust verwendet?

Erstens und am wichtigsten ist, dass diese Änderung nur Auswirkungen auf Client-Anwendungen hat, die eine Verbindung zu Microsoft Dataverse herstellen. Sie hat keine Auswirkungen auf benutzerdefinierte Plug-Ins, Workflow-Aktivitäten oder lokale/IFD-Dienstverbindungen.

  • Wenn Ihr Code Benutzerkonto- und Kennwortanmeldeinformationen für die Authentifizierung bei Dataverse oder einer Anwendung verwendet, verwenden Sie wahrscheinlich das WS-Trust-Sicherheitsprotokoll. Einige Beispiele werden unten gezeigt, wobei diese Liste nicht vollständig ist.

    • Bei Verwendung der Klasse CrmServiceClient oder ServiceClient mit einer Verbindungszeichenfolge:

      connectionString="AuthType=Office365; Username=jsmith\@contoso.onmicrosoft.com;Password=passcode;Url=https://contoso.crm.dynamics.com"

    • Wenn Sie die Konstruktoren der Klasse OrganizationServiceProxy verwenden:

using (OrganizationServiceProxy organizationServiceProxy =
    new OrganizationServiceProxy(serviceManagement, clientCredentials)
{ ... }

  • Wenn Ihr Code die OrganizationServiceProxy-Klasse überhaupt verwendet, verwenden Sie WS-Trust.

  • Wenn Ihr Code CrmServiceClient.OrganizationServiceProxy verwendet, verwenden Sie WS-Trust.

Was sollte ich tun, um meinen Anwendungscode zu reparieren, falls er betroffen ist?

Es gibt sehr einfache Möglichkeiten, den Code Ihrer Anwendung so zu ändern, dass die empfohlene Verbindungsschnittstelle für die Authentifizierung mit Dataverse verwendet wird.

Wichtig

Halten Sie Ihre Anwendungen mit unseren neuesten Client-SDK-API-Änderungen auf dem neuesten Stand, indem Sie die neuesten verfügbaren NuGet-Pakete wann immer möglich herunterladen und verwenden.

  • Wenn Ihr Code eine OrganizationServiceProxy-Instanz verwendet:

    Wenn Sie die Instanz OrganizationServiceProxy an verschiedene Methoden weitergeben oder die Instanz aus einer Methode zurückgeben, ersetzen Sie alle Vorkommen des Typs OrganizationServiceProxy durch die Schnittstelle IOrganizationService. Diese Schnittstelle stellt alle Kernmethoden zur Verfügung, die für die Kommunikation mit Dataverse verwendet werden.

    Wenn Sie den Konstruktor aufrufen, sollten Sie alle Konstruktoren der Klasse OrganizationServiceProxy durch Konstruktoren der Klasse CrmServiceClient oder ServiceClient ersetzen. Der Einfachheit halber müssen Sie hier jedoch Ihr Codierungsmuster ändern. CrmServiceClient und ServiceClient unterstützen neben komplexen Konstruktoren und der Möglichkeit, externe Handler für die Authentifizierung bereitzustellen, auch Verbindungsstrings. Die Client-Klassen des Dienstes implementieren IOrganizationService, so dass Ihr neuer Authentifizierungscode auf den restlichen Code Ihrer Anwendung übertragbar sein wird. Beispiele für die Verwendung von Service Client Calls finden Sie im PowerApps-Samples Repository.

  • Wenn Ihr Code ServiceClient- oder CrmServiceClient-Klassen mit dem Authentifizierungstyp „Office365“ verwendet:

    Ein Beispiel dafür ist eine Verbindungszeichenfolge, die wie folgt aussieht:

    connectionString = "AuthType=Office365;Username=jsmith@contoso.onmicrosoft.com;Password=passcode;Url=https://contoso.crm.dynamics.com"

    In ähnlicher Weise könnten Sie auch einen CrmServiceClient oder ServiceClient Konstruktor verwenden und AuthType.Office365 übergeben.

    • Wechseln Sie zur Verwendung einer OAuth-basierten Verbindungszeichenfolge. Eine solche Verbindungszeichenfolge sieht wie folgt aus:

      connectionString = "AuthType=OAuth;Username=jsmith@contoso.onmicrosoft.com;
Password=passcode;Url=https://contosotest.crm.dynamics.com;AppId=51f81489-12ee-4a9e-aaae-a2591f45987d;
RedirectUri=app://58145B91-0C36-4500-8554-080854F2AC97;LoginPrompt=Auto"`

      Dies ist der schnellste Weg, den Code zu aktualisieren. Beachten Sie, dass LoginPrompt auf „nie“ gesetzt werden kann, um die Funktionsweise des Office365-Verhaltens zu simulieren.

      Die oben angegebenen AppId und RedirectUri sind Beispiele für funktionierende Anwendungsregistrierungswerte. Diese Werte funktionieren überall dort, wo unsere Online-Dienste eingesetzt werden. Sie dienen hier jedoch lediglich als Beispiele und Sie sollten keine Bedenken haben, Ihre eigene Anwendungsregistrierung in Microsoft Entra ID für Anwendungen zu erstellen, die in Ihrem Mandanten ausgeführt werden. Verwenden Sie Ihren Benutzernamen, Ihr Passwort und Dataverse-Umgebungs-URL-Werte in der Verbindungszeichenfolge zusammen mit „RedirectUri“ und „AppId“, die Sie von Ihrer Azure-App-Registrierung erhalten.

  • Wenn Sie auf den CrmServiceClient zugreifen.OrganizationServiceProxy Eigenschaft:

    Entfernen Sie jegliche Verwendung dieser Eigenschaft in Ihrem Code. Die Klassen CrmServiceClient und ServiceClient implementieren IOrganizationService und legen alles offen, was für den Proxy des Organisationsdienstes einstellbar ist.

Wichtig

Was die Möglichkeit betrifft, sich nicht mit Benutzer-ID/Passwort anzumelden, selbst wenn OAuth verwendet wird: Wenn Ihr Mandant und Benutzer in Microsoft Entra ID für die Zugangsberechtigung konfiguriert ist und/oder Multi-Faktor-Authentifizierung erforderlich ist, können Sie Benutzer-ID/Passwort-Flows überhaupt nicht in einer nicht-interaktiven Form verwenden. In diesen Situationen müssen Sie einen Dienstprinzipal-Benutzer verwenden, um sich bei Dataverse zu authentifizieren.

Dazu müssen Sie zunächst den Anwendungsbenutzer (Service Principal) mit Microsoft Entra ID registrieren. Wie Sie dies tun können, erfahren Sie hier. Während der Anwendungsregistrierung müssen Sie diesen Benutzer in Dataverse erstellen und Berechtigungen erteilen. Diese Berechtigungen können entweder direkt oder indirekt erteilt werden, indem der Anwendungsbenutzer einem Team hinzugefügt wird, dem in Dataverse Berechtigungen erteilt wurden. Weitere Informationen zum Einrichten eines nicht lizenzierten „Anwendungsbenutzers“ zur Authentifizierung mit Dataverse finden Sie hier .

Brauchen Sie Hilfe?

Wir werden die Power Apps ALM- und ProDev-Community-Foren überwachen. Bitte schauen Sie dort nach, um Hilfe bei der Lösung verschiedener Probleme zu erhalten oder eine Frage zu stellen.

Siehe auch

Verwenden von Verbindungszeichenfolgen im XRM-Tooling zur Herstellung einer Verbindung mit Microsoft Dataverse

Hinweis

Können Sie uns Ihre Präferenzen für die Dokumentationssprache mitteilen? Nehmen Sie an einer kurzen Umfrage teil. (Beachten Sie, dass diese Umfrage auf Englisch ist.)

Die Umfrage dauert etwa sieben Minuten. Es werden keine personenbezogenen Daten erhoben. (Datenschutzbestimmungen).