Partager via

Active Directory et authentification basée sur les revendications

  • Article

 

Date de publication : janvier 2017

S’applique à : Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

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 Microsoft Dynamics 365 (Online et local) ) 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 Microsoft Dynamics 365. Toutes les éditions Microsoft Dynamics 365 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, consultez la rubrique suivante dans la documentation Déploiement et administration de Dynamics 365 : TechNet : Configuration d'IFD pour Microsoft Dynamics CRM 2015.

Contenu de la rubrique

Scénarios d’authentification pris en charge

Scénarios d’authentification non pris en charge

Classes d’authentification

Authentification via des classes proxy clientes

Gestion des exceptions et des défauts de canal

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

Scénarios d’authentification pris en charge

Microsoft Dynamics 365 prend en charge les scénarios d’authentification suivants pour chaque type de déploiement.

Déploiement

Modèle d'authentification

Microsoft Dynamics 365 (Online)

Authentification basée sur les revendications ou Active Directory (via la fédération)

Microsoft Dynamics 365 local

Authentification basée sur les revendications ou Active Directory

Microsoft Dynamics 365Déploiement avec accès via Internet (IFD)

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 Microsoft Dynamics 365 ou Microsoft Dynamics 365 (Online) ou d’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 Microsoft Dynamics 365 ou une application personnalisée vers Active Directory. La pile WCF gère le processus d’authentification des appels d’API du service d’organisation à partir d’une application, alors qu’Internet Information Services (IIS) gère 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 par le SDK de Microsoft Dynamics 365. Si vous configurez le site Web Microsoft Dynamics 365 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.

Pour plus d’informations sur les méthodes de programmation non prises en charge supplémentaires, 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 Microsoft Dynamics 365 (en ligne)

Exemple : Authentifier les utilisateurs avec des services Web Microsoft Dynamics 365

Verbessern der Servicekanal-Zuteilungsleistung

DiscoveryServiceProxy, OrganizationServiceProxy

Tous les types de déploiement : local/IFD, en ligne (Compte Microsoft et Office 365/MOS*)

Authentification via des classes proxy clientes

Exemple : Accéder au service de découverte

Verbessern der Servicekanal-Zuteilungsleistung

Classe CrmConnection

Tous les types de déploiement : local/IFD, en ligne (Compte Microsoft et Office 365/MOS*)

Connexion simplifiée à Microsoft Dynamics CRM

Exemple : démarrage rapide de la connexion simplifiée avec Microsoft Dynamics 365

ServerConnection

Tous les types de déploiement : local/IFD, en ligne (Compte Microsoft et Office 365/MOS*)

À utiliser pour les applications test de console et un exemple de code.

Conçu pour une meilleure utilisation lors de l’exécution de l’exemple de code du SDK et pour illustrer l’utilisation des classes d’authentification. Contient un code de sortie de la console.

Code d’assistance : classe ServerConnection

Exemple : Démarrage rapide de Microsoft Dynamics 365

*Environnement Microsoft Online Services

Authentification via des classes proxy clientes

L’authentification auprès des services Web de Microsoft Dynamics 365 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 les déploiements de Microsoft Dynamics 365 (Online et local). 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 Microsoft Dynamics 365 (Online) via le fournisseur d’identité 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 Microsoft Dynamics 365, les classes proxy clientes utilisent l’authentification basée sur les revendications si un serveur STS est disponible. Sinon, lorsque l’authentification Active Directory est utilisée.

Si vous souhaitez utiliser les types d’entités à liaison anticipée Microsoft Dynamics 365 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()
System_CAPS_security Sécurité Remarque

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 Microsoft Dynamics 365, 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.

Microsoft Dynamics 365 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 le SDK de Microsoft Dynamics 365 pour obtenir la liste des exceptions supplémentaires à détecter :

Pour plus d’informations, voir la Documentation WCF de .NET Framework sur la gestion des défauts et des exceptions WCF. Pour obtenir un autre code d’exemple, voir Utiliser l’exemple de code et le code d’assistance.

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 Microsoft Dynamics 365 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 Microsoft Dynamics 365 cible.

Nom

Si l’utilisateur authentifié est également un administrateur de déploiement dans Microsoft Dynamics 365, cette revendication contient l’ID de l’administrateur de déploiement au format domaine\alias sur le serveur Microsoft Dynamics 365 cible.Windows Identity Foundation mappe la revendication Name à la propriété Identity.name.

Autres revendications

Non utilisées par Microsoft Dynamics 365.

Types de jeton de sécurité pris en charge

Microsoft Dynamics 365 (Online et local) prennent en charge deux types de jetons SAML :

  • Application Web - L’application Web Microsoft Dynamics 365 reçoit un jeton porteur de STS. Certaines informations requises sont manquantes dans ce jeton ; par conséquent, une URL basée sur TLS (Transport Layer Security) ou SSL (Secure Sockets Layer)(https://) est utilisée pour la protection de 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 Microsoft Dynamics 365 lorsque la requête de messages suivante de votre application est traitée.

Voir aussi

Guide pas-à-pas : Enregistrer une application Dynamics 365 auprès d'Active Directory
Se connecter à Microsoft Office 365 et Microsoft Dynamics 365 (en ligne)
Implémenter une authentification unique d’une page Web ASPX ou IFRAME
Exemple : Authentifier les utilisateurs avec des services Web Microsoft Dynamics 365

Microsoft Dynamics 365

© 2017 Microsoft. Tous droits réservés. Copyright