Partager via

Utilisation de l’authentification Office365 avec Microsoft Dataverse

  • Article

Important

L’utilisation du protocole de sécurité d’authentification WS-Trust (Office365) lors de la connexion à Microsoft Dataverse n’est plus recommandée. Autrement dit, elle est déconseillée ; voir l’annonce.

De plus, le protocole WS-Trust ne prend pas en charge les formes modernes d’authentification multifacteur et les contrôles d’accès conditionnels Microsoft Entra ID aux données client.

Ce document décrit l’impact sur les applications clientes personnalisées qui utilisent l’authentification « Office365 » et les classes OrganizationServiceProxy, ServiceClient ou CrmServiceClient. Si vos applications utilisent ce type de protocole d’authentification et d’API, continuez à lire ci-dessous pour en savoir plus sur les modifications d’authentification recommandées à apporter au code de votre application.

Comment savoir si mon code ou mon application utilise WS-Trust ?

Tout d’abord et surtout, ce changement impacte seulement les applications clientes qui se connectent au Microsoft Dataverse. Il n’affecte pas les plug-ins personnalisés, les activités de workflow ou les connexions de service sur site/IFD.

  • Si votre code utilise des informations d’identification de compte d’utilisateur et de mot de passe pour l’authentification avec Dataverse ou une application, vous utilisez probablement le protocole de sécurité WS-Trust. Quelques exemples sont présentés ci-dessous, bien que cette liste ne soit pas entièrement inclusive.

    • Lorsque vous utilisez la classe CrmServiceClient ou ServiceClient avec une chaîne de connexion :

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

    • Lors de l’utilisation de constructeurs de classe OrganizationServiceProxy :

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

  • Si votre code utilise la classe OrganizationServiceProxy, vous utilisez WS-Trust.

  • Si votre code utilise CrmServiceClient.OrganizationServiceProxy, vous utilisez WS-Trust.

Que dois-je faire pour corriger mon code d’application s’il est affecté ?

Il existe des moyens très simples de modifier le code de votre application pour utiliser l’interface de connexion recommandée pour l’authentification avec Dataverse.

Important

Tenez vos applications à jour avec nos dernières modifications de l’API SDK client en téléchargeant et en utilisant les derniers packages NuGet disponibles, dans la mesure du possible.

  • Si votre code utilise une instance OrganizationServiceProxy :

    Si vous passez l’instance OrganizationServiceProxy à diverses méthodes, ou si vous renvoyez l’instance à partir d’une méthode, remplacez toutes les occurrences du type OrganizationServiceProxy avec l’interface IOrganizationService. Cette interface expose toutes les méthodes principales utilisées pour communiquer avec Dataverse.

    Lors de l’appel du constructeur, il est recommandé de remplacer toute utilisation des constructeurs de classe OrganizationServiceProxy par des constructeurs de classe CrmServiceClient ou ServiceClient. Vous devrez cependant modifier votre modèle de codage ici ; pour plus de simplicité CrmServiceClient et ServiceClient prennent en charge les chaînes de connexion en plus des constructeurs complexes et la possibilité de fournir des gestionnaires d’authentification externes. Les classes de client de service mettent en oeuvre IOrganizationService, par conséquent, votre nouveau code d’authentification sera portable pour le reste de votre code d’application. Vous trouverez des exemples d’utilisation des classes de client de service dans le référentiel Exemples PowerApps.

  • Si votre code utilise les classes ServiceClient ou CrmServiceClient avec le type d’authentification « Office365 » :

    Un exemple de ceci est une chaîne de connexions qui ressemble à ceci :

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

    De même, vous pouvez également utiliser un constructeur CrmServiceClient ou ServiceClient et transmettre dans AuthType.Office365.

    • Passez à l’utilisation d’une chaîne de connexion basée sur OAuth. Une telle chaîne de connexion ressemble à ceci :

      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"`

      Ce sera votre moyen le plus rapide de mettre à jour le code. Notez que LoginPrompt peut être défini sur "jamais" pour simuler le fonctionnement du comportement Office365.

      Les AppId et RedirectUri fournis ci-dessus sont des exemples de valeurs d’enregistrement d’application qui fonctionnent. Ces valeurs fonctionnent partout où nos services en ligne sont déployés. Cependant, ils sont fournis ici à titre d’exemples et nous vous encourageons à créer votre propre inscription d’application dans Microsoft Entra ID pour les applications exécutées dans votre locataire. Utilisez votre nom d’utilisateur, votre mot de passe et les valeurs d’URL d’environnement Dataverse dans la chaîne de connexion avec le RedirectUri et l’AppId que vous obtenez à partir de votre inscription d’application Azure.

  • Si vous accédez à la propriété CrmServiceClient.OrganizationServiceProxy  :

    Supprimez toute utilisation de cette propriété dans votre code. Les classes CrmServiceClient et ServiceClient mettent en oeuvre IOrganizationService et exposent tout ce qui est paramétrable pour le proxy de service d’organisation.

Important

Concernant ne pas pouvoir se connecter en utilisant l’ID utilisateur/mot de passe même si vous utilisez OAuth : si votre client et utilisateur est configuré dans Microsoft Entra ID pour un accès conditionnel et/ou qu’une authentification multifacteur est requise, vous ne pourrez pas du tout utiliser les flux d’ID utilisateur/mot de passe sous une forme non interactive. Dans ces situations, vous devez utiliser un utilisateur principal du service pour vous authentifier auprès de Dataverse.

Pour ce faire, vous devez d’abord enregistrer l’utilisateur de l’application (principal du service) dans Microsoft Entra ID. Vous pouvez découvrir comment procéder ici. Lors de l’enregistrement de l’application, vous devrez créer cet utilisateur dans Dataverse et accorder des autorisations. Ces autorisations peuvent être accordées directement ou indirectement en ajoutant l’utilisateur de l’application à une équipe qui a obtenu des autorisations dans Dataverse. Vous pouvez trouver plus d’informations sur la façon de configurer un « utilisateur d’application » sans licence pour s’authentifier avec Dataverse ici.

Besoin d’aide ?

Nous surveillerons les forums de la communauté ALM et ProDev de Power Apps. Veuillez y jeter un œil pour obtenir de l’aide sur la façon de résoudre divers problèmes ou publier une question.

Voir aussi

Utiliser les chaînes de connexion des outils XRM pour se connecter à Microsoft Dataverse

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).