Planifier les méthodes d’authentification utilisateur dans SharePoint Server

 

**Sapplique à :**SharePoint Server 2013, SharePoint Server 2016

**Dernière rubrique modifiée :**2017-06-21

**Résumé :**Apprenez à planifier l’utilisation des différentes méthodes d’authentification utilisateur pour créer une expérience sécurisée pour les utilisateurs des applications web dans SharePoint Server 2013 et SharePoint Server 2016.

Découvrez les types et les méthodes d’authentifications utilisateur pris en charge par SharePoint Server et comment déterminer ceux à utiliser pour les applications et les zones web.

Dans cet article :

• Introduction

• Authentification basée sur les revendications

• Types et méthodes d'authentification pris en charge

• Planifier l’authentification Windows

• Planifier l'authentification basée sur les formulaires

• Planifier l'authentification basée sur un jeton SAML

• Planification des zones des applications Web

Introduction

L’authentification d’utilisateur est la validation de l’identité de l’utilisateur auprès d’un fournisseur d’authentification, c’est-à-dire un répertoire ou une base de données qui contient les informations d’identification de l’utilisateur et permet de confirmer qu’elles ont été entrées correctement. Services de domaine Active Directory (AD DS), par exemple, est un fournisseur d’authentification. D’autres termes sont employés pour désigner un fournisseur d’authentification, comme annuaire d’utilisateurs et magasin d’attributs.

Une méthode d’authentification est un échange spécifique d’informations d’identification des comptes et d’autres informations qui prouvent l’identité d’un utilisateur. Le résultat de la méthode d’authentification permet de prouver, généralement sous la forme d’un jeton contenant des revendications, qu’un fournisseur d’authentification a authentifié un utilisateur.

Un type d’authentification est une méthode spécifique de validation des informations d’identification auprès d’un ou de plusieurs fournisseurs d’authentification, parfois selon un protocole standard de l’industrie. Un type d’authentification peut utiliser plusieurs méthodes d’authentification.

Une fois l’identité d’un utilisateur validée, le processus d’autorisation détermine à quels sites, contenus et autres fonctionnalités l’utilisateur peut accéder.

Votre planification des types et des méthodes d’authentification des utilisateurs doit déterminer les points suivants :

• Types et méthodes d’authentification des utilisateurs pour chaque zone et application Web

• Infrastructure d’authentification nécessaire pour prendre en charge les types et méthodes d’authentifications déterminés

  Notes

  L’authentification Windows en mode classique n’est plus prise en charge dans SharePoint Server 2016.

Authentification basée sur les revendications

L’identité des utilisateurs dans AD DS est basée sur un compte d’utilisateur. Pour que l’authentification aboutisse, l’utilisateur fournit le nom de compte et la preuve de connaissance du mot de passe. Pour déterminer l’accès aux ressources, les applications doivent éventuellement demander les attributs de compte et d’autres informations au service AD DS, par exemple l’appartenance au groupe ou le rôle sur le réseau. Cette méthode fonctionne dans les environnements Windows, mais n’est pas adaptée aux fournisseurs d’authentification tiers ni aux environnements multifournisseurs qui prennent en charge les modèles d’informatique basés sur Internet, les partenaires ou le nuage.

Avec les identités basées sur les revendications, les utilisateurs obtiennent un jeton de sécurité signé numériquement par un fournisseur d’identité approuvé. Le jeton contient un ensemble de revendications, chacune représentant un élément spécifique des données concernant un utilisateur, par exemple son nom, ses appartenances à des groupes et son rôle sur le réseau. L’authentification basée sur les revendications est l’authentification d’utilisateur qui repose sur les technologies et l’infrastructure d’identité basée sur les revendications. Les applications qui prennent en charge l’authentification basée sur les revendications obtiennent un jeton de sécurité d’un utilisateur, au lieu d’informations d’identification, et utilisent les informations des revendications pour déterminer l’accès aux ressources. Aucune demande séparée à un service d’annuaire tel qu’AD DS n’est nécessaire.

L’authentification basée sur les revendications dans Windows repose sur Windows Identity Foundation (WIF), qui est un ensemble de classes .NET Framework servant à implémenter l’identité basée sur les revendications. L’authentification basée sur les revendications repose sur des normes telles que WS-Federation et WS-Trust, et sur des protocoles tels que SAML (Security Assertion Markup Language).

Pour plus d’informations sur l’authentification basée sur les revendications, voir les ressources suivantes :

• Identité basée sur les revendications pour Windows (livre blanc)

• Page d’accueil de Windows Identity Foundation

En raison de l’utilisation répandue de l’authentification basée sur les revendications pour l’authentification utilisateur, l’authentification de serveur à serveur et l’authentification d’application, nous vous recommandons d’utiliser l’authentification basée sur les revendications pour l’ensemble des applications et des zones web d’une batterie de serveurs SharePoint Server. Pour plus d’informations, consultez la rubrique Planifier l’authentification de serveur à serveur dans SharePoint Server. Quand vous utilisez l’authentification basée sur les revendications, toutes les méthodes d’authentification sont disponibles pour vos applications web et vous pouvez bénéficier de nouvelles fonctionnalités et de nouveaux scénarios dans SharePoint Server qui utilisent l’authentification de serveur à serveur et l’authentification d’application.

Pour l’authentification basée sur les revendications, SharePoint Server modifie automatiquement tous les comptes d’utilisateur en identités de revendications, ce qui génère un jeton de sécurité (également appelé jeton de revendication) pour chaque utilisateur. Le jeton de revendication contient les revendications liées à l’utilisateur. Les comptes Windows sont convertis en revendications Windows. Les utilisateurs d’une appartenance basée sur les formulaires sont convertis en revendications d’authentification basée sur les formulaires. SharePoint Server peut utiliser les revendications incluses dans les jetons SAML. Par ailleurs, les développeurs et les administrateurs SharePoint peuvent ajouter des revendications supplémentaires aux jetons utilisateur. Par exemple, les comptes d’utilisateur Windows et les comptes d’utilisateur basés sur les formulaires peuvent obtenir des revendications supplémentaires utilisées par SharePoint Server.

Il n’est pas nécessaire d’être architecte de revendications pour utiliser l’authentification basée sur les revendications dans SharePoint Server. Toutefois, l’implémentation de l’authentification basée sur les jetons SAML nécessite une coordination avec les administrateurs de votre environnement basé sur les revendications, comme décrit dans la section Planifier l'authentification basée sur un jeton SAML.

Authentification classique dans SharePoint Server 2013

Dans SharePoint 2013, quand vous créez une application web dans l’Administration centrale, vous pouvez uniquement spécifier les types et les méthodes d’authentification pour l’authentification basée sur les revendications. Dans des versions précédentes de SharePoint, vous pouviez également configurer l’authentification en mode classique pour les applications web dans l’Administration centrale. L’authentification en mode classique utilise l’authentification Windows et SharePoint 2013 traite les comptes d’utilisateur comme des comptes AD DS.

Pour configurer une application web pour utiliser l’authentification en mode classique, vous devez utiliser la cmdlet New-SPWebApplication PowerShell pour la créer. Les applications web Produits SharePoint 2010 qui sont configurées pour l’authentification en mode classique conservent leurs paramètres d’authentification à la suite d’une mise à niveau vers SharePoint 2013. Nous vous recommandons toutefois de transférer vos applications web vers l’authentification basée sur les revendications avant d’effectuer la mise à niveau vers SharePoint 2013.

Une batterie de serveurs SharePoint 2013 peut inclure une combinaison d’applications web qui utilisent les deux modes. Certains services ne font pas la différence entre les comptes d’utilisateur Windows traditionnels et les comptes basés sur les revendications Windows.

Pour plus d’informations sur la migration avant la mise à niveau, voir Migrer de l’authentification en mode classique vers l’authentification basée sur les revendications.

Pour plus d’informations sur la migration après la mise à niveau, voir Migrer de l’authentification en mode classique vers l’authentification basée sur les revendications dans SharePoint 2013.

Pour plus d’informations sur la création d’applications web qui utilisent l’authentification en mode classique dans SharePoint 2013, voir Create web applications that use classic mode authentication in SharePoint Server. Notez que vous ne pouvez pas transférer une application web qui utilise l’authentification basée sur les revendications vers l’authentification en mode classique.

Types et méthodes d’authentification pris en charge

SharePoint Server prend en charge différents fournisseurs et méthodes d’authentification pour les types d’authentification suivants :

• Authentification Windows

• Authentification basée sur les formulaires

• Authentification basée sur un jeton SAML

Authentification Windows

Le type d’authentification Windows bénéficie de votre fournisseur d’authentification Windows actuelle (AD DS) et des protocoles d’authentification utilisés par un environnement de domaine Windows pour valider les informations d’identification des clients qui se connectent. Les méthodes d’authentification Windows, qui sont utilisées par l’authentification basée sur les revendications, incluent les éléments suivants :

• NTLM

• Kerberos

• Digest

• De base

Pour plus d’informations, voir Planifier l’authentification Windows dans cet article.

Regardez la vidéo sur l’authentification basée sur les revendications Windows dans SharePoint 2013 et SharePoint Server 2016

Même s’il n’est pas un type d’authentification Windows, SharePoint Server prend également en charge l’authentification anonyme. Les utilisateurs peuvent accéder au contenu SharePoint sans valider leurs informations d’identification. L’authentification anonyme est désactivée par défaut. Elle sert généralement quand vous utilisez SharePoint Server pour publier du contenu qui ne nécessite pas de sécurité et est disponible pour tous les utilisateurs, par exemple un site web public.

Notez qu’en plus de l’activation de l’authentification anonyme, vous devez configurer l’accès anonyme (autorisations) aux sites et aux ressources des sites.

Authentification basée sur les formulaires

L’authentification basée sur les formulaires est un système de gestion d’identité basée sur les formulaires qui repose sur l’authentification par fournisseur de rôles et d’appartenance ASP.NET. L’authentification basée sur les formulaires peut être utilisée sur des informations d’identification stockées chez un fournisseur d’authentification, par exemple :

• AD DS ;

• une base de données telle que SQL Server ;

• un magasin de données LDAP (Lightweight Directory Access Protocol) tel que Novell eDirectory, NDS (Novell Directory Services) ou Sun ONE.

L’authentification basée sur les formulaires valide les utilisateurs en fonction des informations d’identification qu’ils ont entrées dans un formulaire d’ouverture de session (généralement, une page web). Les demandes non authentifiées sont redirigées vers une page de connexion dans laquelle l’utilisateur doit fournir des informations d’identification valides et envoyer le formulaire. Le système émet un cookie pour les demandes authentifiées qui contiennent une clé permettant de rétablir l’identité pour les demandes suivantes.

Regardez la vidéo sur l’authentification basée sur les formulaires (revendications) dans SharePoint 2013 et SharePoint Server 2016

Pour plus d’informations, voir Planifier l'authentification basée sur les formulaires.

Authentification basée sur un jeton SAML

L’authentification basée sur les jetons SAML dans SharePoint Server utilise le protocole SAML 1.1 et la norme WS-F PRP (WS-Federation Passive Requestor Profile). Elle nécessite une coordination avec les administrateurs d’un environnement basé sur les revendications, qu’il s’agisse de votre propre environnement interne ou d’un environnement partenaire. Si vous utilisez les services AD FS (Active Directory Federation Services) 2.0, votre environnement est basé sur les revendications.

Un environnement d’authentification basée sur les jetons SAML inclut un fournisseur d’identité IP-STS (identity provider security token service). L’IP-STS émet des jetons SAML pour le compte des utilisateurs ayant leurs comptes chez le fournisseur d’authentification associé. Les jetons peuvent inclure un nombre indéfini de revendications sur un utilisateur, par exemple un nom d’utilisateur et les groupes auxquels il appartient. Un serveur AD FS 2.0 est un exemple d’IP-STS.

SharePoint Server exploite les revendications incluses dans les jetons émis par un IP-STS pour les utilisateurs autorisés. Dans les environnements de revendications, une application qui accepte les jetons SAML porte le nom de STS de partie de confiance (RP-STS). Une application de partie de confiance reçoit le jeton SAML et utilise les revendications qu’il contient pour décider si le client peut accéder à la ressource demandée. Dans SharePoint Server, chaque application web configurée pour utiliser un fournisseur SAML est ajoutée au serveur IP-STS en tant qu’entrée RP-STS distincte. Une batterie SharePoint peut comprendre plusieurs entrées RP-STS dans l’IP-STS.

Regardez la vidéo sur l’authentification basée sur les revendications SAML dans SharePoint 2013 et SharePoint Server 2016

L’ensemble des fournisseurs d’authentification pour l’authentification basée sur un jeton SAML dépend de l’IP-STS de votre environnement de revendications. Si vous utilisez AD FS 2.0, les fournisseurs d’authentification (connus comme magasins d’attributs pour AD FS 2.0) peuvent inclure les éléments suivants :

• Windows Server 2003 Active Directory et AD DS dans Windows Server 2008 ;

• toutes les éditions de SQL Server 2005 et de SQL Server 2008 ;

• des magasins d’attributs personnalisés.

Pour plus d’informations, voir Planifier l'authentification basée sur un jeton SAML.

Choix des types d’authentification pour les environnements LDAP

L’authentification basée sur les formulaires ou sur un jeton SAML peut utiliser les environnements LDAP. Vous devez utiliser le type d’authentification qui correspond à votre environnement LDAP actuel. Si vous n’en possédez pas encore, nous vous recommandons d’utiliser l’authentification basée sur les formulaires, car elle est moins complexe. Cependant, si votre environnement d’authentification prend déjà en charge WS-Federation 1.1 et SAML 1.1, nous vous conseillons d’utiliser SAML. SharePoint Server intègre un fournisseur LDAP.

Planifier l’authentification Windows

Le processus de planification et d’implémentation des méthodes d’authentification Windows est semblable pour l’authentification basée sur les revendications. L’authentification basée sur les revendications pour une application web ne complique pas l’implémentation des méthodes d’authentification Windows. Cette section présente une synthèse de la planification des méthodes d’authentification Windows.

NTLM et protocole Kerberos

NTLM et le protocole Kerberos sont des méthodes d’authentification Windows intégrées, qui permettent aux utilisateurs de procéder à l’authentification de façon transparente sans demande d’informations d’identification. Par exemple :

• Les utilisateurs qui accèdent aux sites SharePoint à partir d’Internet Explorer utilisent les informations d’identification sous lesquelles s’exécute le processus Internet Explorer. Par défaut, il s’agit des informations d’identification employées par l’utilisateur pour ouvrir une session sur l’ordinateur.

• Les services ou applications qui utilisent les méthodes d’authentification Windows intégrées pour accéder aux ressources SharePoint tentent de s’authentifier à l’aide des informations d’identification du thread en cours d’exécution qui, par défaut, correspondent à l’identité du processus.

NTLM est la forme d’authentification Windows la plus simple à implémenter et ne demande généralement aucune configuration supplémentaire de l’infrastructure d’authentification. Il suffit de sélectionner cette option quand vous créez ou configurez l’application web.

Le protocole Kerberos prend en charge l’authentification par ticket. Son utilisation nécessite une configuration supplémentaire de l’environnement. Pour activer l’authentification Kerberos, les ordinateurs client et serveur doivent disposer d’une connexion approuvée au centre de distribution de clés du domaine. Pour configurer le protocole Kerberos, vous devez configurer des noms de principaux du service (SPN) dans les services AD DS avant d’installer SharePoint Server.

Voici les avantages de l’authentification Kerberos :

• Le protocole Kerberos est le protocole d’authentification Windows intégrée le plus fort et prend en charge des fonctionnalités avancées de sécurité, notamment le chiffrement AES (Advanced Encryption Standard) et l’authentification mutuelle de clients et de serveurs.

• Le protocole Kerberos autorise la délégation des informations d’identification du client.

• Parmi les méthodes d’authentification sécurisée disponibles, Kerberos est celle qui nécessite le moins de trafic réseau vers les contrôleurs de domaine AD DS. Suivant les scénarios, Kerberos peut réduire la latence des pages ou augmenter le nombre de pages qu’un serveur web frontal peut servir. Kerberos peut également réduire la charge sur les contrôleurs de domaine.

• Le protocole Kerberos est ouvert et pris en charge par un grand nombre de plateformes et de fournisseurs.

Voici les inconvénients de l’authentification Kerberos :

• Comparée à d’autres méthodes, l’authentification Kerberos nécessite une configuration supplémentaire de l’infrastructure et de l’environnement pour fonctionner correctement. Dans de nombreux cas, il est nécessaire de détenir l’autorisation d’administrateur de domaine pour configurer le protocole Kerberos. L’authentification Kerberos peut être difficile à configurer et à gérer. Une mauvaise configuration de Kerberos peut entraîner l’échec de l’authentification auprès de vos sites.

• L’authentification Kerberos nécessite que l’ordinateur client dispose d’une connexion à un centre de distribution de clés (KDC) et à un contrôleur de domaine des services de domaine Active Directory (AD DS, Active Directory Domain Services). Dans un déploiement Windows, le KDC est un contrôleur de domaine AD DS. Bien qu’il s’agisse d’une configuration réseau courante dans l’intranet d’une organisation, les déploiements exposés à Internet ne sont généralement pas configurés de la sorte.

Les étapes suivantes résument la configuration de l’authentification Kerberos :

1. Configurez l’authentification Kerberos pour les communications SQL Server en créant des SPN dans AD DS pour le compte de service SQL Server.

2. Créez des SPN pour les applications Web qui utiliseront l’authentification Kerberos.

3. Installez la batterie de serveurs SharePoint Server.

4. Configurez des services particuliers dans la batterie de façon à utiliser des comptes spécifiques.

5. Créez les applications Web qui utiliseront l’authentification Kerberos.

Digest et de base

Avec la méthode d’authentification Digest, les informations d’identification de compte d’utilisateur sont envoyées sous forme de résumé de message MD5 au service Internet Information Services (IIS) sur le serveur web qui héberge l’application ou la zone web. Avec la méthode d’authentification de base, les informations de compte d’utilisateur sont envoyées sous forme de texte brut. Vous ne devez donc pas utiliser la méthode d’authentification de base, sauf si vous utilisez le chiffrement SSL (Secure Sockets Layer) pour chiffrer le trafic du site web.

Vous devrez peut-être utiliser ces anciennes méthodes d’authentification si votre environnement utilise des navigateurs ou des services web qui prennent en charge uniquement l’authentification Digest ou de base des sites web.

Contrairement aux méthodes d’authentification NTLM, Kerberos et anonyme, vous devez configurer les méthodes Digest et de base à partir des propriétés du site web qui correspond à l’application ou la zone web du logiciel enfichable Internet Information Services (IIS).

Si vous utilisez l’authentification basée sur les revendications, reportez-vous aux articles suivants :

• Configurer l’authentification Digest pour une application web basée sur les revendications dans SharePoint 2013

• Configurer l’authentification de base pour une application Web basée sur les revendications dans SharePoint 2013

Planifier l’authentification basée sur les formulaires

Pour utiliser l’authentification basée sur les formulaires pour authentifier les utilisateurs dans un système de gestion d’identité qui n’est pas basé sur Windows ou qui est externe, vous devez enregistrer le fournisseur d’appartenances et le gestionnaire de rôles dans le fichier Web.config. SharePoint Server utilise l’interface du gestionnaire de rôles ASP.NET standard pour collecter des informations de groupe sur l’utilisateur actuel. Chaque rôle ASP.NET est traité comme un groupe de domaines par le processus d’autorisation dans SharePoint Server. Pour enregistrer les gestionnaires de rôles dans le fichier Web.config, procédez exactement comme pour enregistrer les fournisseurs d’appartenances pour l’authentification.

Si vous souhaitez gérer les utilisateurs d’appartenances (membership users) ou les rôles à partir du site web Administration centrale, vous devez inscrire le fournisseur d’appartenances et le gestionnaire de rôles dans le fichier Web.config du site web Administration centrale. Vous devez également inscrire le fournisseur d’appartenances et le gestionnaire de rôles dans le fichier Web.config de l’application web qui héberge le contenu.

Pour obtenir les étapes détaillées de configuration de l’authentification basée sur les formulaires, voir Configurer l’authentification basée sur les formulaires pour une application web basée sur les revendications dans SharePoint 2013

Planifier l’authentification basée sur un jeton SAML

L’architecture d’implémentation des fournisseurs basés sur un jeton SAML inclut les composants suivants :

• Service d’émission de jeton de sécurité SharePoint   Ce service crée les jetons SAML utilisés par la batterie. Il est créé et démarré automatiquement sur tous les serveurs d’une batterie de serveurs. On l’utilise pour les communications entre les batteries, car toutes les communications entre les batteries utilisent l’authentification basée sur les revendications. Ce service est également utilisé pour les méthodes d’authentification qui sont mises en œuvre pour les applications web qui utilisent l’authentification basée sur les revendications, notamment l’authentification Windows, l’authentification basée sur les formulaires et l’authentification basée sur le jeton SAML.

• Certificat de signature de jetons (ImportTrustCertificate)   Il s’agit du certificat exporté à partir d’un service IP-STS, puis copié sur un serveur de la batterie et ajouté à la liste Autorités racines approuvées de la batterie de serveurs. Quand vous avez utilisé ce certificat pour créer un SPTrustedIdentityTokenIssuer, vous ne pouvez pas l’utiliser pour en créer un autre. Pour utiliser le certificat pour créer un autre SPTrustedIdentityTokenIssuer, vous devez d’abord supprimer celui qui existe. Avant cela, vous devez le dissocier de toutes les applications web susceptibles de l’utiliser.

• Revendication d’identité   La revendication d’identité est la revendication tirée d’un jeton SAML qui constitue l’identificateur unique de l’utilisateur. Seul le propriétaire du service IP-STS connaît la valeur dans le jeton qui est unique pour chaque utilisateur. La revendication d’identité est créée en tant que mappage de revendications ordinaire lors du mappage de toutes les revendications souhaitées. La revendication qui sert de revendication d’identité est déclarée lors de la création du SPTrustedIdentityTokenIssuer.

• Autres revendications   Il s’agit des revendications supplémentaires d’un ticket SAML, qui décrivent les utilisateurs. Il peut s’agir de rôles utilisateurs, de groupes d’utilisateurs ou d’autres types de revendications telles que l’âge. Tous les mappages de revendications sont créés en tant qu’objets répliqués sur les serveurs d’une batterie SharePoint Server.

• Domaine   Dans l’architecture de revendications de SharePoint, l’URI ou URL associée à une application web SharePoint configurée de façon à utiliser un fournisseur basé sur les jetons SAML représente un domaine. Quand vous créez un fournisseur d’authentification basé sur les jetons SAML dans la batterie, vous spécifiez un à la fois les domaines, ou URL d’applications web, que vous souhaitez que le service IP-STS reconnaisse. Vous spécifiez le premier domaine lors de la création du SPTrustedIdentityTokenIssuer. Vous pouvez ajouter des domaines après avoir créé le SPTrustedIdentityTokenIssuer. Vous devez spécifier les domaines à l’aide d’une syntaxe semblable à la suivante : $realm = "urn:sharepoint:mysites". Après avoir ajouté le domaine au SPTrustedIdentityTokenIssuer, vous devez créer une approbation RP-STS avec l’identificateur de domaine sur le serveur IP-STS. Ce processus nécessite de spécifier l’URL de l’application web.

• SPTrustedIdentityTokenIssuer   Il s’agit de l’objet créé dans la batterie SharePoint qui inclut les valeurs nécessaires pour communiquer avec le service IP-STS et recevoir des jetons à partir de ce service. Lors de la création du SPTrustedIdentityTokenIssuer, vous spécifiez le certificat de signature de jetons à utiliser, le premier domaine, la revendication qui représente la revendication d’identité et les éventuelles revendications supplémentaires. Vous ne pouvez associer un certificat de signature de jetons d’un service STS qu’à un seul SPTrustedIdentityTokenIssuer. Toutefois, une fois le SPTrustedIdentityTokenIssuer créé, vous pouvez ajouter des domaines supplémentaires pour d’autres applications web. Une fois le domaine ajouté au SPTrustedIdentityTokenIssuer, vous devez également l’ajouter au service IP-STS en tant que partie de confiance. L’objet SPTrustedIdentityTokenIssuer est répliqué sur les serveurs de la batterie SharePoint Server.

• RP-STS (Relying Party Security Token Service)   Dans SharePoint Server, chaque application web configurée de façon à utiliser un fournisseur SAML est ajoutée au serveur IP-STS comme entrée RP-STS. Une batterie SharePoint Server peut comprendre plusieurs entrées RP-STS.

• Service IP-STS (Identity Provider Security Token Service)   Il s’agit du service d’émission de jetons de sécurité dans l’environnement de revendications qui émet les jetons SAML pour le compte des utilisateurs figurant dans l’annuaire d’utilisateurs associé.

Le diagramme suivant représente l’architecture des revendications de jeton SAML SharePoint Server.

Architecture des revendications de jeton SAML

L’objet SPTrustedIdentityTokenIssuer est créé avec plusieurs paramètres, notamment les suivants :

• Une revendication d’identité unique

• Un paramètre SignInURL unique

  Le paramètre SignInURL spécifie l’URL vers laquelle rediriger une demande d’utilisateur pour s’authentifier auprès du service IP-STS.

• Un paramètre Wreply unique

  Certains serveurs IP-STS nécessitent le paramètre Wreply, qui prend la valeur true ou false. Cette dernière est la valeur par défaut. Utilisez le paramètre Wreply uniquement si le service IP-STS le demande.

• Plusieurs domaines

• Plusieurs mappages de revendications

Pour implémenter l’authentification basée sur un jeton SAML avec SharePoint Server, appliquez les étapes suivantes, qui doivent être planifiées :

1. Exportez le certificat de signature de jetons à partir du service IP-STS. Copiez le certificat dans un serveur de la batterie SharePoint Server.

2. Définissez la revendication qui sera utilisée comme identificateur unique de l’utilisateur. Elle porte le nom de revendication d’identité. Le nom d’utilisateur principal (UPN) ou nom de messagerie de l’utilisateur est souvent utilisé comme identificateur d’utilisateur. Collaborez avec l’administrateur du service IP-STS pour déterminer l’identificateur correct, car seul le propriétaire du service IP-STS sait quelle valeur dans le jeton sera toujours unique pour chaque utilisateur. L’identification de l’identificateur unique de l’utilisateur fait partie du processus de mappage de revendications. Microsoft PowerShell permet de créer les mappages de revendications.

3. Définissez les mappages de revendications supplémentaires. Définissez les revendications supplémentaires du jeton entrant qui seront utilisées par la batterie SharePoint Server. Les rôles utilisateurs sont un exemple de revendication pouvant être utilisée pour accorder des autorisations aux ressources dans la batterie SharePoint Server. Toutes les revendications d’un jeton entrant qui ne possèdent pas de mappage sont rejetées.

4. PowerShell permet de créer un fournisseur d’authentification pour importer le certificat de signature de jetons. Ce processus crée le SPTrustedIdentityTokenIssuer. Durant ce processus, vous spécifiez la revendication d’identité et les revendications supplémentaires que vous avez mappées. Vous devez également créer et spécifier un domaine associé aux premières applications web SharePoint que vous configurez pour l’authentification basée sur les jetons SAML. Une fois le SPTrustedIdentityTokenIssuer créé, vous pouvez créer et ajouter davantage de domaines pour d’autres applications web SharePoint. C’est ainsi que vous configurez plusieurs applications web de façon à utiliser le même SPTrustedIdentityTokenIssuer.

5. Pour chaque domaine ajouté au SPTrustedIdentityTokenIssuer, vous devez créer une entrée RP-STS sur le service IP-STS. Cette opération peut s’effectuer avant la création de l’application web SharePoint. Quoi qu’il en soit, vous devez planifier l’URL avant de créer les applications web.

6. Configurez une application web SharePoint, nouvelle ou existante, pour utiliser le nouveau fournisseur d’authentification. Ce dernier figure en tant que fournisseur d’identité approuvé dans l’Administration centrale quand vous créez une application web.

Vous pouvez configurer plusieurs fournisseurs d’authentification basée sur les jetons SAML. Cependant, vous ne pouvez utiliser un certificat de signature de jetons qu’une seule fois dans une batterie. Tous les fournisseurs configurés apparaissent comme des options dans l’Administration centrale. Les revendications issues de différents environnements STS approuvés n’entrent pas en conflit.

Si vous implémentez l’authentification basée sur les jetons SAML avec une société partenaire et que votre propre environnement comprend un service IP-STS, nous vous recommandons d’établir, avec l’administrateur de votre environnement de revendications interne, une relation d’approbation entre votre service IP-STS interne et le service STS partenaire. En adoptant cette approche, vous n’avez pas besoin d’ajouter un fournisseur d’authentification à votre batterie SharePoint Server. De plus, votre administrateur de revendications peut gérer l’ensemble de l’environnement de revendications.

Pour obtenir les étapes détaillées de configuration de l’authentification basée sur un jeton SAML avec AD FS, voir Configurer l’authentification basée sur les revendications SAML avec les services ADFS dans SharePoint 2013.

Planification des zones des applications Web

Les zones représentent différents itinéraires logiques permettant d’accéder aux mêmes sites dans une application web. Chaque application web peut inclure jusqu’à cinq zones. Lors de la création d’une application web, l’Administration centrale crée la zone par défaut. Pour créer des zones supplémentaires, étendez l’application web et sélectionnez l’un des noms de zones restants : intranet, extranet, Internet ou personnalisé.

Votre plan pour les zones Web dépendra des éléments suivants :

• Authentification basée sur les revendications (recommandé) : vous pouvez implémenter plusieurs fournisseurs d’authentification sur une même zone. Vous pouvez également utiliser plusieurs zones.

Implémentation de plusieurs types d’authentification sur une même zone

Si vous utilisez l’authentification basée sur les revendications et que vous implémentez plusieurs méthodes d’authentification, nous vous recommandons d’implémenter plusieurs méthodes d’authentification sur la zone par défaut. Le résultat est la même URL pour tous les utilisateurs.

Lorsque vous implémentez plusieurs méthodes d’authentification sur la même zone, les restrictions suivantes sont applicables :

• Vous pouvez implémenter uniquement une instance de l’authentification basée sur les formulaires sur une zone.

• L’Administration centrale permet d’utiliser conjointement l’authentification Windows intégrée et l’authentification de base. Autrement, il est impossible d’implémenter plusieurs types d’authentification Windows sur une zone.

Si plusieurs fournisseurs d’authentification basée sur les jetons SAML sont configurés pour une batterie, ils apparaîtront tous comme options lors de la création d’une application web ou d’une zone. Vous pouvez configurer plusieurs fournisseurs SAML sur la même zone.

Le diagramme suivant illustre plusieurs types d’authentification implémentés sur la zone par défaut pour un site de collaboration partenaire.

Plusieurs types d’authentification implémentés sur la zone par défaut

Sur le diagramme, les utilisateurs de différents magasins d’annuaires accèdent au site web partenaire à l’aide de la même URL. Le cadre en pointillés qui entoure les sociétés partenaires indique la relation entre l’annuaire d’utilisateurs et le type d’authentification configuré dans la zone par défaut.

Planification de l’analyse du contenu

Le composant d’analyse nécessite NTLM pour accéder au contenu. Au moins une zone doit être configurée de façon à utiliser l’authentification NTLM. Si l’authentification NTLM n’est pas configurée sur la zone par défaut, le composant d’analyse peut utiliser une zone différente configurée de façon à utiliser l’authentification NTLM.

Implémenter plusieurs zones

Si vous souhaitez implémenter plusieurs zones pour les applications Web, suivez les instructions suivantes :

• Utilisez la zone par défaut pour implémenter les paramètres d’authentification les plus sécurisés. Si une demande ne peut pas être associée à une zone spécifique, les paramètres d’authentification et autres stratégies de sécurité de la zone par défaut sont appliqués. La zone par défaut est créée quand vous créez une application web. En règle générale, les paramètres d’authentification les plus sécurisés sont conçus pour l’accès de l’utilisateur final. Ainsi, les utilisateurs finaux sont susceptibles d’accéder à la zone par défaut.

• Utilisez le nombre minimal de zones requises pour l’accès des utilisateurs. Chaque zone est associée à un nouveau site IIS et domaine Services Internet (IIS) pour accéder à l’application web. Ajoutez de nouveaux points d’accès uniquement lorsqu’ils sont nécessaires.

• Vérifiez qu’au moins une zone est configurée pour utiliser l’authentification NTLM pour le composant d’analyse. Ne créez pas de zone réservée au composant d’index, sauf en cas de nécessité.

Le diagramme suivant représente plusieurs zones implémentées de façon à gérer différents types d’authentification pour un site de collaboration partenaire.

Une zone par type d’authentification

Sur le diagramme, la zone par défaut est utilisée pour les employés distants. Chaque zone est associée à une URL différente. Les employés utilisent une zone différente selon qu’ils travaillent au bureau ou à distance.