Utilisez l'authentification de serveur à serveur multi-utilisateurs
Date de publication : janvier 2017
S’applique à : Dynamics 365 (online)
Il s'agit du scénario le plus courant et celui qui est utilisé pour les applications distribuées avec Microsoft AppSource, mais vous pouvez également utiliser l'authentification multi-utilisateurs sans répertorier votre application avec Microsoft AppSource.
Chaque organisation Dynamics 365 (en ligne) est associée à un client Azure Active Directory (Azure AD). Votre application ou service Web est enregistrée avec son propre client Azure AD.
Dans ce scénario, un client Dynamics 365 (en ligne) peut potentiellement utiliser votre application à plusieurs clients après l'avoir autorisée à accéder aux données.
Contenu de la rubrique
Configuration requise
Vue d'ensemble : Développer et tester votre application
Créez un utilisateur de l'application associé à l'application enregistrée dans Dynamics 365
Testez votre application au moyen de votre client Dynamics 365
Testez votre application au moyen d'un client Dynamics 365 distinct
Préparer une méthode pour déployer l'utilisateur de l'application
Configuration requise
Pour créer et tester une application à plusieurs utilisateurs qui utilise l'authentification de serveur à serveur (S2S) vous aurez besoin de :
Un client Azure AD que vous utiliserez pour publier votre application ou service.
2 abonnements Dynamics 365 (en ligne)
L'un doit être associé à un client Azure AD que vous utiliserez pour publier votre application ou service.
L'autre peut être un abonnement d'évaluation à utiliser pour tester la manière dont un abonné accédera à votre application.
Vue d'ensemble : Développer et tester votre application
L'application que vous allez créer doit être enregistrée auprès du client Azure AD que vous utiliserez lorsque vous publierez l'application.
À un niveau supérieur, le processus se compose des éléments suivants :
Créez une application Web à plusieurs utilisateurs enregistrée auprès de votre client Azure AD.
Créez un utilisateur de l'application associé à l'application enregistrée dans votre client Dynamics 365 (en ligne)
Créez un rôle de sécurité personnalisé et attribuez-le à l'utilisateur de l'application de votre client Dynamics 365 (en ligne)
Testez votre application au moyen de votre client Dynamics 365 (en ligne)
Testez votre application au moyen d'un client Dynamics 365 (en ligne) distinct
Pour obtenir un exemple complet de ce processus, voir Guide pas-à-pas : authentification de serveur à serveur multi-utilisateurs.
Créez une application Web à plusieurs utilisateurs enregistrée auprès de votre client Azure AD
Vous allez créer une application Web ou un service à plusieurs utilisateurs qui utilise Azure AD comme fournisseur d'authentification.
Cette rubrique ne traitera pas de la procédure exacte. Bien des méthodes permettent d'aborder cela et de faire des choix adaptés à vos besoins ou préférences. Pour plus d’informations et d'exemples, voir les liens suivants :
Créer une application Web SaaS à plusieurs utilisateurs à l'aide de Azure AD et OpenID Connect
Créer une application Web SaaS à plusieurs utilisateurs qui appelle une API Web à l'aide de Azure AD
Azure AD nécessite les valeurs suivantes pour enregistrer votre application :
Valeur |
Description |
---|---|
URI de l'ID d'application |
Identificateur d'une application. Cette valeur est envoyée à Azure AD pendant l'authentification pour indiquer pour quelle application l'appelant souhaite un jeton. En outre, cette valeur est incluse dans le jeton afin que l'application sache qu'il était la cible prévue. |
URL de réponse et URI de redirection |
Dans le cas d'une API Web ou d'une application Web, l'URL de réponse est l'emplacement où Azure AD enverra la réponse d'authentification, notamment un jeton si l'authentification a réussi. |
ID client |
ID d'une application, qui est généré par Azure AD lorsque l'application est enregistrée. Lors de la demande d'un code d'autorisation ou d'un jeton, l'ID client et une clé sont envoyés à Azure AD pendant l'authentification. |
Clé |
Clé qui est envoyée avec un ID client lors de l'authentification auprès de Azure AD pour appeler une API Web. |
Lorsque l'application sera enregistrée un Id d'objet Azure Active Directory (identificateur unique de l'application enregistrée) lui sera attribué.
Si vous créez une application MVC ASP.NET avec Visual Studio 2015 vous aurez des options pour spécifier que l'application peut prendre en charge la fonctionnalité à plusieurs utilisateurs. Le modèle d'une application MVC fournit la possibilité de spécifier le type d'authentification ayant lieu. Vous aurez la possibilité de choisir la méthode d'authentification en configurant les propriétés de votre projet lors de la création. Le diagramme suivant illustre les options disponibles :
Lorsque vous configurerez un projet avec ces options il sera configuré pour utiliser le logiciel intermédiaire OWIN et la génération de modèles automatique pour une application de base qui prend en charge ce scénario. Avec quelques modifications de base il peut être adapté pour utiliser Dynamics 365 (en ligne). Il s'agit de l'approche illustrée dans Guide pas-à-pas : authentification de serveur à serveur multi-utilisateurs.
Lors du processus de création et d'enregistrement de votre application à des fins de développement vous utiliserez probablement https://localhost comme valeurs de URL de connexion et de URL de réponse afin de pouvoir tester et déboguer votre application localement avant de la publier. Vous devrez modifier ces valeurs avant de publier votre application.
Lorsque vous enregistrez votre application vous devez générer une clé, également appelée ClientSecret. Ces clés sont configurées pour une durée d'un ou deux ans. En tant qu'hôte de l'application vous devez traiter cette valeur comme un mot de passe et il est de votre responsabilité de gérer le renouvellement des clés avant qu'elles expirent. Vous pouvez utiliser Azure Key Vault.Pour plus d'informations :https://azure.microsoft.com/fr-fr/services/key-vault/
Accordez vos droits d'application pour accéder aux données Dynamics 365 (en ligne)
C'est la raison pour laquelle votre instance de Dynamics 365 (en ligne) doit être associée à votre client Azure AD. Si votre client Azure AD n'est pas associé à un client Dynamics 365 (en ligne), vous ne pourrez pas procéder comme suit.
Accédez à https://portal.azure.com et sélectionnez Azure Active Directory.
Cliquez sur Inscriptions d'application et recherchez l'application que vous avez créée à l'aide de Visual Studio.
Vous devez attribuer à vos privilèges d'application l'accès aux données Dynamics 365 (en ligne). Dans la zone Accès API, cliquez sur Autorisations requises. Vous devriez voir qu'il possède déjà des autorisations pour Windows Azure Active Directory.
Dans Ajouter, puis sur Sélectionner une API. Dans la liste, sélectionnez Dynamics 365, puis cliquez sur le bouton Sélectionner.
Dans Sélectionner les autorisations, sélectionnez Accéder à Dynamics 365 en tant qu'utilisateurs de l'organisation. Cliquez ensuite sur le bouton Sélectionner.
Cliquez sur Terminé pour ajouter ces autorisations. Lorsque vous avez terminé vous devez voir les autorisations appliquées.
Créez un utilisateur de l'application associé à l'application enregistrée dans Dynamics 365
Lorsque votre application accède aux données Dynamics 365 d'un des abonnés de votre application, elle nécessite un utilisateur de l'application dans l'organisation Dynamics 365 de l'abonné. Comme tout utilisateur Dynamics 365, cet utilisateur de l'application doit être associé à au moins un rôle de sécurité qui définit les données auxquelles l'utilisateur a accès.
L'entité systemuser inclut trois nouveaux attributs pour stocker ces données.
Nom du schéma |
Nom complet |
Type |
Description |
---|---|---|---|
ApplicationId |
ID d'application |
UniqueidentifierType |
Identificateur de l'application. Il permet d'accéder à des données dans une autre application. |
ApplicationIdUri |
URI de l'ID d'application |
StringType |
URI utilisé comme identificateur logique unique de l'application externe. Il peut être utilisé pour valider l'application |
AzureActiveDirectoryObjectId |
ID d'objet Azure AD |
UniqueidentifierType |
ID d'objet du répertoire de l'application. |
Cette valeur de propriété systemuserAzureActiveDirectoryObjectId doit être une référence à l'ID d'objet Azure Active Directory de votre application enregistrée. Cette référence sera définie dans Dynamics 365 lorsque l'utilisateur de l'application est créé en fonction de la valeur ApplicationId.
Notes
Lorsque vous développez initialement votre application avec votre propre client Dynamics 365 et le client Azure AD qui y est associé, vous pouvez simplement créer l'utilisateur de l'application car l'application enregistrée fait déjà partie de votre client Azure AD.
Toutefois, afin de créer l'utilisateur de l'application dans une autre organisation à des fins de tests, ou lorsqu'un abonné utilisera votre application, ils doivent d'abord accorder leur consentement à votre application, et donc les étapes du processus diffèrent. Pour plus d'informations, voir Testez votre application au moyen d'un client Dynamics 365 distinct.
Créer un rôle de sécurité pour l'utilisateur de l'application
Dans l'étape suivante vous allez créer utilisateur de l'application Dynamics 365. Les privilèges et les droits d'accès de cet utilisateur sont définis par un rôle de sécurité personnalisé que vous définissez. Avant de créer l'application, vous devez créer un rôle de sécurité personnalisé de manière à pouvoir associer l'utilisateur à celui-ci. Plus d'informations : TechNet : Créer ou modifier un rôle de sécurité
Notes
L'utilisateur de l'application ne peut pas être associé à l'un des rôles de sécurité Dynamics 365 par défaut. Vous devez créer un rôle de sécurité personnalisé à associer à l'utilisateur de l'application.
Créer manuellement un utilisateur de l'application Dynamics 365
La procédure pour créer cet utilisateur est différente de celle de la création d'un utilisateur autorisé. Effectuez les opérations suivantes :
Accédez à Paramètres > Sécurité > Utilisateurs
Dans la liste déroulante Afficher, sélectionnez Utilisateurs d’application.
Cliquez sur Nouveau. Vérifiez tandis que vous utilisez le formulaire Utilisateur de l'application.
Si vous ne voyez pas les champs ID d'application, URI de l'ID d'application et ID d'objet Azure AD dans le formulaire, vous devez sélectionner le formulaire Utilisateur de l'application dans la liste :
Ajoutez les valeurs appropriées aux champs :
Champ
Valeur
ID d'application
Valeur de l'ID d'application de l'application enregistrée auprès d'Azure AD.
Nom complet
Nom de votre application.
Adresse de messagerie principale
Adresse de messagerie que vous souhaitez que vos abonnés utilisent pour vous contacter.
Les champs Nom d’utilisateur, URI de l'ID d'application et ID d'objet Azure AD sont verrouillés et vous ne pouvez pas définir les valeurs de ces champs.
Lorsque vous créez cet utilisateur les valeurs de ces champs sont récupérées auprès de Azure AD selon la valeur ID d'application lorsque vous enregistrez l'utilisateur.
Associez l'utilisateur de l'application au rôle de sécurité personnalisé créé dans Créer un rôle de sécurité pour l'utilisateur de l'application. Plus d'informations : TechNet : Attribuer un rôle de sécurité à un utilisateur
Testez votre application au moyen de votre client Dynamics 365
Étant donné que l'application a été enregistrée avec votre client Azure AD et que l'utilisateur de l'application de votre organisation de développement est déjà configuré, vous pouvez continuer à développer votre application dans votre propre client Dynamics 365. Mais cela n'est pas un test valide de la fonctionnalité à plusieurs utilisateurs. Vous devez tester votre application sur un client Dynamics 365 distinct.
Testez votre application au moyen d'un client Dynamics 365 distinct
Avant de tester votre application avec un client Dynamics 365 distinct, un administrateur du client Azure AD doit accorder son consentement pour l'application. L'administrateur accorde son consentement en accédant à l'application avec un navigateur. La première fois qu'il accède à l'application, il voit une boîte de dialogue comme celle-ci :
Lorsqu'il accorde son consentement, votre application enregistrée est ajoutée à la liste des applications d'entreprise Azure AD et elle est disponible pour les utilisateurs du client Azure AD.
Une fois seulement qu'un administrateur a accordé son consentement, vous devez créer l'utilisateur de l'application dans le client Dynamics 365 de l'abonné. Vous pouvez créer manuellement l'utilisateur de l'application à l'aide des étapes décrites dans Créer manuellement un utilisateur de l'application Dynamics 365.
Pour les tests initiaux vous pouvez effectuer la procédure suivante manuellement. Lorsque vous serez prêt à rendre votre application ou service disponible pour les abonnés, vous souhaiterez avoir une procédure plus efficace. Cela est expliqué dans la section suivante.
Préparer une méthode pour déployer l'utilisateur de l'application
Une fois que les abonnés auront accordé leur consentement pour votre application ou service, vous aurez besoin d'un moyen simple et fiable d'ajouter l'utilisateur de l'application et tous les autres composants nécessaires à leur organisation Dynamics 365.
Vous devez inclure un rôle de sécurité personnalisé qui définit les privilèges que votre application requiert puis faire en sorte que l'utilisateur de l'application soit associé à ce rôle de sécurité personnalisé. Du fait qu'un rôle de sécurité personnalisé puisse être inclus dans une solution, vous devez préparer une solution gérée qui contient la définition du rôle de sécurité personnalisé et tous les autres composants de solution que votre application requiert.
Pour des informations sur la création de rôles de sécurité personnalisés, voir
Pour plus d'informations sur la création d'une solution Dynamics 365, consultez les rubriques suivantes :
TechNet : Utilisation de solutions pour vos personnalisations
Empaqueter et distribuer les extensions à l’aide des solutions
Toutefois, l'utilisateur de l'application ne peut pas être inclus dans une solution, vous devrez donc fournir une façon de créer cet utilisateur de l'application et de l'associer au rôle de sécurité personnalisé.
Il existe plusieurs méthodes permettant d'y parvenir, notamment en écrivant votre propre programme à l'aide du SDK de Microsoft Dynamics 365 et en faisant exécuter le programme par l'abonné.
Le SDK de Microsoft Dynamics 365 fournit une application Système de déploiement de packages de CRM qui permet de préparer un package afin d'automatiser le transfert des solutions et des données vers une autre organisation Dynamics 365.Pour plus d'informations :Créer des packages pour l’outil Package Deployer Dynamics 365
Voir aussi
Guide pas-à-pas : authentification de serveur à serveur multi-utilisateurs
Utilisez l'authentification de serveur à serveur mono-utilisateur
Créer des applications Web en utilisant l'authentification de serveur à serveur (S2S)
Connexion à Microsoft Dynamics 365
Microsoft Dynamics 365
© 2017 Microsoft. Tous droits réservés. Copyright