Active Directory et authentification basée sur les revendications
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.
* 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é
SupportInteractiveest automatiquement définie surfalse.- Si les informations d’identification sont explicitement fournies par votre code, la valeur actuelle de
SupportInteractiveest transmise à la fabrique de canaux WCF.SupportInteractiveest défini surtruepar défaut à moins que vous ne le modifiiez explicitement. - Si la propriété
SupportInteractiveest définie surtrueet 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.
- Si les informations d’identification sont explicitement fournies par votre code, la valeur actuelle de
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 :
FaultException<DiscoveryServiceFault>
Pour plus d’informations, voir la Documentation de WCF .NET Framework sur la gestion des défauts et des exceptions WCF.
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