Active Directory et authentification basée sur les revendications

  • Article

L’authentification basée sur les revendications fournit un protocole de sécurité standard pour authentifier un utilisateur sur un ordinateur hôte. L’authentification basée sur les revendications est un ensemble de normes WS-* décrivant l’utilisation d’un jeton SAML (Security Assertion Markup Language) en mode passif (lorsque WS-Federation est utilisée avec l’application web de Dynamics 365 for Customer Engagement) ou en mode actif (lorsque WS-Trust est utilisé avec les clients Windows Communication Foundation (WCF)). Cette authentification fonctionne avec WCF pour fournir une authentification de l’utilisateur et un canal de communication sécurisés avec un serveur Dynamics 365 Server. Toutes les éditions Dynamics 365 Customer Engagement (on-premises) prennent en charge de l’authentification basée sur les revendications.

L’authentification basée sur les revendications nécessite la disponibilité d’un service d’émission de jeton de sécurité (STS) exécuté sur un serveur. Un serveur STS peut être basé sur Active Directory Federation Services (AD FS) V2, ou une plateforme qui fournit le protocole STS officiel. Pour plus d’informations : TechNet : Configurer IFD pour Dynamics 365 Customer Engagement (on-premises).

Scénarios d’authentification pris en charge

Dynamics 365 Customer Engagement (on-premises) prend en charge les scénarios d’authentification suivants pour chaque type de déploiement.

 

Déploiement Modèle d’authentification
Dynamics 365 for Customer Engagement (on-premises) Authentification basée sur les revendications ou Active Directory
Déploiement avec accès via Internet de Dynamics 365 for Customer Engagement Authentification basée sur les revendications ou Active Directory

Fonctionnement de l’authentification basée sur les revendications

Une demande d’authentification d’un utilisateur est envoyée depuis Dynamics 365 for Customer Engagement ou une application personnalisée au serveur STS. Le serveur STS détermine si l’utilisateur doit s’authentifier et, dans ce cas-là, émet un jeton SAML signé et chiffré qui contient les informations d’authentification utilisateur. Le jeton a une durée de vie limitée et peut être régulièrement actualisé en fonction de la durée pendant laquelle votre application utilise le jeton. Ceci est présenté plus en détail plus loin dans cette rubrique.

Fonctionnement de l’authentification Active Directory

Une demande d’authentification d’un utilisateur est envoyée depuis les applications Dynamics 365 Customer Engagement (on-premises) ou d’une application personnalisée à Active Directory. La pile WCF gère le processus d’authentification des appels d’API du service d’organisation à partir d’une application, alors que les services d’informations Internet gèrent l’authentification pour une application web.

Scénarios d’authentification non pris en charge

L’utilisation des certificats clients n’est pas prise en charge. Si vous configurez le site Web Dynamics 365 Customer Engagement pour qu’il requiert des certificats clients IIS, vous recevrez des erreurs d’authentification pour toutes les applications qui ont été créées avec le Kit de développement logiciel (SDK).

Pour plus d’informations sur les autres méthodes de programmation non prises en charge, voir Personnalisations non prises en charge.

Classes d’authentification

Le tableau suivant répertorie les principales classes d’authentification disponibles dans le SDK, explique quand les utiliser et fournit des liens vers de la documentation supplémentaire appropriée.

Classes Utilisation Documentation connexe
IServiceConfiguration<TService>, IServiceManagement<TService> Tous les types de déploiement : local/IFD, en ligne (compte Microsoft et Office 365/MOS*)

Le meilleur choix pour les applications multi-thread		 Authentifier les utilisateurs d’Office 365 avec les services Web Dynamics 365 Customer Engagement

Exemple : Authentifier les utilisateurs d’Office 365 avec les services Web Dynamics 365 Customer Engagement

Améliorer les performances d’allocation des canaux de service
DiscoveryServiceProxy, OrganizationServiceProxy Tous les types de déploiement : local/IFD, en ligne (compte Microsoft et Office 365/MOS*) Authentification via des classes proxy clientes

Améliorer les performances d’allocation des canaux de service
Classes d’outils XRM Tous les types de déploiement : local/IFD, en ligne (compte Microsoft et Office 365/MOS*) Créer des applications clientes Windows à l’aide des outils XRM
CrmServiceClient Tous les types de déploiement : local/IFD, en ligne (compte Microsoft et Office 365/MOS*) Exemple : démarrage rapide de la connexion simplifiée avec Microsoft Dataverse

* Environnement Microsoft Online Services

Pourboire

Selon votre scénario d’application, la méthode recommandée pour authentifier une application client .NET Framework avec tout déploiement de Dynamics 365 Customer Engagement (on-premises) consiste à utiliser la classe CrmServiceClient.

N’utilisez pas la classe ServiceClient si vous utilisez ADFS pour l’authentification sur site.

Authentification via des classes proxy clientes

L’authentification auprès des services web de Dynamics 365 Customer Engagement (on-premises) peut être effectué en utilisant les classes OrganizationServiceProxy et DiscoveryServiceProxy dans les applications que vous écrivez. Le constructeur à quatre paramètres de ces classes prend en charge le déploiement de Dynamics 365 for Customer Engagement. Ces classes proxy gèrent automatiquement les revendications ou l’authentification Active Directory, ainsi que les limitations de ressources sur le point de terminaison des canaux WCF.

Le code suivant montre comment instancier le proxy du service d’organisation :

using (OrganizationServiceProxy _serviceProxy = new OrganizationServiceProxy(organizationUri, homeRealmUri, userCredentials, deviceCredentials))

Le code suivant montre comment instancier le proxy du service de découverte :

using (DiscoveryServiceProxy _discProxy = new DiscoveryServiceProxy(organizationUri, homeRealmUri, userCredentials, deviceCredentials))

Il est important de se débarrasser correctement de l’instance de proxy du service dans votre application avant que l’application prenne fin. L’instruction using vérifie que le proxy du service est correctement supprimé en appelant automatiquement Dispose sur le proxy du service lorsqu’il sort de l’étendue. Toutefois, pour améliorer les performances de l’application, il est recommandé de maintenir l’instance du proxy de service disponible dans votre application pour toute la durée de la session de l’application plutôt que de la supprimer et de l’allouer à nouveau ailleurs dans le code d’application lorsque nécessaire. Ceci est dû au fait que la création et l’authentification d’un canal de service est une opération coûteuse (en temps). Dans ce cas, lorsque vous avez terminé avec l’instance du proxy de service, vous devez directement appeler la méthode Dispose sur le proxy avant que l’application ne se ferme.

Les informations d’identification appareil du périphérique informatique enregistré sont uniquement utilisées lors de l’authentification auprès de Dynamics 365 for Customer Engagement via le fournisseur d’identité du compte Microsoft. Pour obtenir un exemple de code qui explique comment renseigner les paramètres de constructeur proxy, voir Exemple : accéder au service de découverte.

Important

Pour une installation locale ou un déploiement Internet (IFD) de Dynamics 365 for Customer Engagement, les classes proxy clientes utilisent l’authentification basée sur les revendications si un serveur STS est disponible. Sinon, l’authentification Active Directory et utilisée.

Si vous souhaitez utiliser les types d’entités à liaison anticipée Dynamics 365 Customer Engagement (on-premises) dans votre code, vous devez ajouter la ligne de code suivante une fois le proxy du service d’organisation instancié, mais avant de passer des appels de méthodes de service web :

_serviceProxy.EnableProxyTypes()

Important

WCF prend en charge une fonctionnalité où il peut interactivement inviter l’utilisateur à entrer des informations d’ouverture de session lorsque cela est nécessaire. Activez cette fonctionnalité en définissant la propriété SupportInteractive de la classe ClientCredentials. Ces informations d’identification sont utilisées dans le paramètre userCredentials, illustré dans l’extrait de code précédent.

En effectuant des appels SDK aux services web de Dynamics 365 Customer Engagement (on-premises), la propriété des modifications de données opérationnelles et d’entité effectuées par l’appel SDK peut être modifiée par cette fonctionnalité WCF indépendante de votre code.

Dynamics 365 Customer Engagement (on-premises) gère les informations d’identification dans les appels du service web comme suit :

  • Si les informations d’identification ne sont pas disponibles dans l’appel du service web, la pile WCF détermine les informations d’identification à utiliser. Dans ce cas, la valeur de la propriété SupportInteractive est automatiquement définie sur false.
    • Si les informations d’identification sont explicitement fournies par votre code, la valeur actuelle de SupportInteractive est transmise à la fabrique de canaux WCF. SupportInteractive est défini sur true par défaut à moins que vous ne le modifiiez explicitement.
    • Si la propriété SupportInteractive est définie sur true et que les informations d’identification fournies défaillent, la boîte de dialogue WCF peut s’afficher. Toutes les informations d’identification entrées par l’utilisateur dans la boîte de dialogue sont utilisées à la place de celles fournies dans les appels du service web que votre application appelle.

Gestion des exceptions et des défauts de canal

Votre code doit déceler les exceptions et les défauts suivants. Consultez les exemples C# dans la documentation pour développeurs pour obtenir une liste d’exceptions supplémentaires à détecter :

Autres informations sur le jeton de sécurité (SAML)

Le jeton SAML utilisé pendant l’authentification de l’utilisateur est décrit ci-dessous.

Contenu du jeton SAML

Le jeton SAML 2.0 basé sur XML contient une identité qui définit une ou plusieurs revendications sur un utilisateur. Ce jeton est transmis entre un serveur du fournisseur d’identité (STS) et Dynamics 365 Customer Engagement (on-premises) pour l’authentification basée sur les revendications. Les revendications dans l’identité ont été définies comme suit.

Revendication Utiliser
Nom principal universel (UPN) Contient l’ID de l’utilisateur au format domaine\alias sur le serveur Dynamics 365 Server cible.
Nom Si l’utilisateur authentifié est également un administrateur de déploiement dans Dynamics 365 Customer Engagement (on-premises), cette revendication contient l’ID de l’administrateur de déploiement au format domaine\alias sur le serveur Dynamics 365 Server cible. Windows Identity Foundation mappe la revendication Name à la propriété Identity.name.
Autres revendications Non utilisées par Dynamics 365 Customer Engagement (on-premises).

Types de jeton de sécurité pris en charge

Dynamics 365 for Customer Engagement prend en charge deux types de jetons SAML :

  • Application web - L’application web Dynamics 365 Customer Engagement (on-premises) reçoit un jeton porteur de STS. Certaines informations nécessaires sont manquantes pour ce jeton et une URL Transport Layer Security (TLS) or Secure Sockets Layer (SSL) (https://) est utilisée pour la protection de la sécurité lorsque vous accédez au point de terminaison WCF.

  • SDK - Une application personnalisée reçoit un jeton actif à une clé de vérification qui contient les informations requises.

Cycle de vie du jeton de sécurité

Un SecurityToken a une durée de vie indiquée dans ses propriétés ValidFrom et ValidTo. Votre conception de l’application doit prendre en compte le risque que le jeton peut expirer, ce qui entraînerait la levée d’une exception ExpiredSecurityTokenException par les services web de Dynamics 365 Customer Engagement (on-premises) lorsque la requête de messages suivante de votre application est traitée.

Voir aussi

Guide pas-à-pas : Enregistrer Dynamics 365 Customer Engagement (on-premises) auprès d’Active Directory
Connecter Microsoft Office 365 et Dynamics 365 Customer Engagement (on-premises)
Implémenter une authentification unique d’une page web ASPX ou IFRAME
Exemple : Authentifier les utilisateurs d’Office 365 avec les services Web Dynamics 365 Customer Engagement