Planifier les méthodes d’authentification utilisateur dans SharePoint Server
S’APPLIQUE À :
2013 2016 2019 Édition d’abonnement 
SharePoint dans Microsoft 365
Remarque
Les méthodes d’authentification utilisateur mentionnées ici s’appliquent à SharePoint Server 2013, SharePoint Server 2016, SharePoint Server 2019 et SharePoint Server Édition d'abonnement.
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.
Découvrez l’authentification SharePoint dans Microsoft 365.
Remarque
Dans SharePoint Server Édition d'abonnement, nous prenons désormais en charge l’authentification OIDC 1.0. Pour plus d’informations sur l’utilisation de ce nouveau type d’authentification, consultez Authentification OpenID Connect 1.0.
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 de compte et d’autres informations qui affirment 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 méthodes d’authentification utilisateur doit déterminer :
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
Remarque
L’authentification en mode classique Windows n’est plus prise en charge dans SharePoint Server 2016, SharePoint Server 2019 et SharePoint Server Édition d'abonnement.
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. Bien que cette fonctionnalité fonctionne bien pour les environnements Windows, elle n’est pas mise à l’échelle vers des fournisseurs d’authentification tiers et des environnements multifournisseurs qui prennent en charge les modèles informatiques Internet, partenaires ou cloud.
Avec les identités basées sur les revendications, un utilisateur obtient un jeton de sécurité signé numériquement auprès d’un fournisseur d’identité généralement approuvé. Le jeton contient un ensemble de revendications. Chaque revendication représente un élément spécifique de données sur les utilisateurs, tels que leurs noms, leurs appartenances aux groupes et leur rôle sur le réseau. L’authentification basée sur les revendications est l’authentification utilisateur qui utilise l’infrastructure et les technologies d’identité basées 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, plutôt que des informations d’identification, et utilisent les informations contenues dans les revendications pour déterminer l’accès aux ressources. Aucune requête distincte à 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 :
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 remplace automatiquement tous les comptes d’utilisateur par des identités de revendications. Cette modification entraîne un jeton de sécurité (également appelé jeton de revendications) pour chaque utilisateur. Le jeton de revendications contient les revendications relatives à l’utilisateur. Les comptes Windows sont convertis en revendications Windows. Les utilisateurs d’appartenance basée sur les formulaires sont transformés en revendications d’authentification basée sur les formulaires. SharePoint Server peut utiliser des revendications incluses dans des jetons SAML. En outre, les développeurs et les administrateurs SharePoint peuvent augmenter les jetons utilisateur avec davantage de revendications. Par exemple, les comptes d’utilisateur Windows et les comptes basés sur des formulaires peuvent être complétés par des revendications supplémentaires utilisées par SharePoint Server.
Vous n’avez pas besoin 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 distinction entre les comptes d’utilisateur qui sont des comptes Windows traditionnels et les comptes de 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 Migrate from classic-mode to claims-based authentication in SharePoint Server.
Pour plus d'informations sur la création d'applications web qui utilisent l'authentification en mode classique dans SharePoint 2013, voir Créer des applications web qui utilisent l'authentification en mode classique dans SharePoint Server. Vous ne pouvez pas migrer une application web qui utilise l’authentification basée sur les revendications pour utiliser l’authentification en mode classique.
Importante
Office Online ne peut être utilisé que par des applications web SharePoint 2013 qui utilisent une authentification basée sur les revendications. Le rendu et la modification dans Office Online ne fonctionneront pas sur des applications web SharePoint 2013 qui utilisent le mode d'authentification classique. Si vous migrez des applications web SharePoint 2010 qui utilisent le mode d'authentification classique vers SharePoint 2013, vous devez les migrer vers une authentification basée sur les revendications pour leur permettre de fonctionner dans Office Online.
Types et méthodes d’authentification pris en charge
SharePoint Server prend en charge différentes méthodes d’authentification et fournisseurs 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. Authentification Windows méthode, qui est utilisée par l’authentification basée sur les revendications, sont les suivantes :
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. Vous utilisez généralement l’authentification anonyme lorsque vous utilisez SharePoint Server pour publier du contenu qui ne nécessite pas de sécurité et qui est disponible pour tous les utilisateurs, comme un site web Internet public.
En plus d’activer l’authentification anonyme, vous devez également configurer l’accès anonyme (autorisations) sur les sites et les ressources du site.
Remarque
Pour les sites web Internet Information Services (IIS) créés par SharePoint pour les applications web, les méthodes d'authentification anonyme et d'authentification par formulaires sont toujours activées, même lorsque les paramètres SharePoint pour l'authentification anonyme et l'authentification par formulaires sont désactivés. Cette configuration est intentionnelle et la désactivation de l'authentification anonyme ou par formulaires directement dans les paramètres IIS génèrera des erreurs dans le site SharePoint.
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 par rapport aux informations d’identification stockées dans 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, où un 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
Remarque
Avec l'authentification basée sur les formulaires, les informations d'identification des utilisateurs sont envoyées sous forme de texte brut. Vous ne devez donc pas utiliser ce type d'authentification, sauf si vous utilisez le chiffrement SSL (Secure Sockets Layer) pour chiffrer le trafic du site web.
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 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 (appelés magasins d’attributs pour AD FS 2.0) peuvent inclure :
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. Utilisez le type d’authentification correspondant à votre environnement LDAP actuel. Si vous n’avez pas encore d’environnement LDAP, 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 n’augmente pas la complexité de l’implémentation de méthodes 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, ces informations d’identification sont les informations d’identification que l’utilisateur a utilisées pour se connecter à 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 de Authentification Windows la plus simple à implémenter et ne nécessite généralement aucune configuration supplémentaire de l’infrastructure d’authentification. Sélectionnez cette option lorsque vous créez ou configurez l’application web.
Le protocole Kerberos prend en charge l'authentification par ticket. L’utilisation du protocole Kerberos nécessite une configuration plus grande 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 que cette configuration réseau soit courante sur un intranet d’organisation, les déploiements accessibles sur Internet ne sont généralement pas configurés de cette manière.
Les étapes suivantes résument la configuration de l'authentification Kerberos :
Configurez l'authentification Kerberos pour les communications SQL Server en créant des SPN dans AD DS pour le compte de service SQL Server.
Créez des SPN pour les applications Web qui utiliseront l'authentification Kerberos.
Installez la batterie de serveurs SharePoint Server.
Configurez des services particuliers dans la batterie de façon à utiliser des comptes spécifiques.
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. Par conséquent, vous ne devez pas utiliser la méthode d’authentification de base, sauf si vous utilisez également SSL 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, consultez :
Planifier l’authentification basée sur les formulaires
Pour utiliser l’authentification basée sur les formulaires afin d’authentifier les utilisateurs auprès d’un système de gestion des identités qui n’est pas basé sur Windows ou qui est externe, vous devez inscrire 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. Inscrivez 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, reportez-vous à l’article Configurer l’authentification par formulaires pour une application web basée sur les revendications dans SharePoint Server
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 de jeton de sécurité SharePoint Ce service crée les jetons SAML que la batterie utilise. Le service est automatiquement créé et démarré sur tous les serveurs d’une batterie de serveurs. Le service est utilisé pour la communication entre batteries, car toutes les communications entre batteries de serveurs utilisent l’authentification basée sur les revendications. Ce service est également utilisé pour les méthodes d’authentification implémentées pour les applications web qui utilisent l’authentification basée sur les revendications. Ces méthodes incluent l’Authentification Windows, l’authentification basée sur les formulaires et l’authentification basée sur les jetons SAML.
Certificat de signature de jeton (ImportTrustCertificate) Ce certificat est celui que vous exportez à partir d’une adresse IP-STS, puis que vous copiez sur un serveur de la batterie de serveurs et que vous l’ajoutez à la liste autorité racine approuvée de la batterie. Une fois que 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 Ces revendications se composent de 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. Lorsque vous créez spTrustedIdentityTokenIssuer, vous spécifiez le certificat de signature de jeton à utiliser, le premier domaine, la revendication qui représente la revendication d’identité et toutes les autres revendications. Vous ne pouvez associer un certificat de signature de jetons d'un service STS qu'à un seul SPTrustedIdentityTokenIssuer. Toutefois, après avoir créé SPTrustedIdentityTokenIssuer, vous pouvez ajouter d’autres domaines pour des applications web supplémentaires. 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 de jeton de sécurité du fournisseur d’identité (IP-STS) Ce service est le jeton sécurisé de l’environnement de revendications qui émet des jetons SAML pour le compte des utilisateurs inclus dans l’annuaire utilisateur 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 :
Une revendication d'identité unique
Paramètre SignInURL unique.
Le paramètre SignInURL spécifie l’URL vers laquelle rediriger une demande d’utilisateur afin de s’authentifier auprès de l’IP-STS.
Paramètre Wreply unique.
Certains serveurs IP-STS nécessitent le paramètre Wreply , qui est défini sur true ou false. Cette dernière est la valeur par défaut. Utilisez le paramètre Wreply uniquement s’il est requis par l’IP-STS.
Plusieurs domaines
Plusieurs mappages de revendications
Pour implémenter l’authentification basée sur les jetons SAML avec SharePoint Server, implémentez les étapes suivantes qui nécessitent une planification à l’avance :
Exportez le certificat de signature de jetons à partir du service IP-STS. Copiez le certificat dans un serveur de la batterie SharePoint Server.
Définissez la revendication qui sera utilisée comme identificateur unique de l'utilisateur. Cette revendication est appelée 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.
Définissez des mappages de revendications supplémentaires. Définissez les revendications supplémentaires du jeton entrant que la batterie de serveurs SharePoint Server utilisera. 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 n’ont pas de mappage sont ignorées.
PowerShell permet de créer un fournisseur d'authentification pour importer le certificat de signature de jetons. Ce processus crée le SPTrustedIdentityTokenIssuer. Au cours de ce processus, vous spécifiez la revendication d’identité et les revendications supplémentaires que vous avez mappées. Créez et spécifiez un domaine associé aux premières applications web SharePoint que vous configurez pour l’authentification basée sur les jetons SAML. Après avoir créé SPTrustedIdentityTokenIssuer, vous pouvez créer et ajouter d’autres domaines pour des applications web SharePoint supplémentaires. Cette procédure vous permet de configurer plusieurs applications web pour utiliser le même SPTrustedIdentityTokenIssuer.
Pour chaque domaine ajouté au SPTrustedIdentityTokenIssuer, vous devez créer une entrée RP-STS sur le service IP-STS. Vous pouvez créer cette entrée avant que l’application web SharePoint existe. Quoi qu'il en soit, vous devez planifier l'URL avant de créer les applications web.
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 de différents environnements STS approuvés ne sont 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 de votre service IP-STS interne vers le service STS partenaire. Cette approche ne vous oblige pas à ajouter un fournisseur d’authentification à votre batterie de serveurs SharePoint Server. Elle permet également à votre administrateur de revendications de gérer l'ensemble de l'environnement de revendications.
Importante
Désormais, vous n’avez plus besoin de définir l’équilibrage de la charge réseau en affinité simple lorsque vous utilisez l’authentification basée sur les revendications dans SharePoint Server.
Remarque
[!REMARQUE] Lorsqu'une application web est configurée pour utiliser l'authentification basée sur un jeton SAML, la classe SPTrustedClaimProvider ne fournit pas de fonctionnalité de recherche au contrôle Sélecteur de personnes. Tout texte entré dans ce contrôle est automatiquement affiché comme s'il avait été résolu, que l'utilisateur, le groupe ou la revendication soient valides ou non. Si votre solution SharePoint Server est appelée à utiliser l'authentification basée sur un jeton SAML, vous devez envisager de créer un fournisseur de revendications personnalisé qui implémente une recherche et une résolution de nom personnalisées.
Pour obtenir les étapes détaillées de configuration de l’authentification basée sur un jeton SAML avec AD FS, consultez la rubrique relative à la configuration de l’authentification basée sur les revendications SAML avec AD FS dans SharePoint Server.
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. Sinon, vous ne pouvez pas implémenter plusieurs types de 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 autre zone configurée pour 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 requête ne peut pas être associée à une zone spécifique, les paramètres d’authentification et les 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. Par conséquent, 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 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 dédiée pour le composant d’index, sauf si cela est nécessaire.
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.