Planifier des méthodes d’authentification (SharePoint Server 2010)

  • Article

 

S’applique à : SharePoint Foundation 2010, SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

Cet article décrit les méthodes et les modes d’authentification pris en charge par Microsoft SharePoint Server 2010. L’authentification est le processus de validation de l’identité d’un utilisateur. 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. Les modes d’authentification déterminent comment les comptes sont utilisés de manière interne par SharePoint Server 2010.

Dans cet article :

  • Méthodes d'authentification prises en charge

  • Modes d'authentification - classique ou basé sur les revendications

  • Implémentation de l'authentification Windows

  • Mise en œuvre de l'authentification par formulaire

  • Mise en œuvre de l'authentification basée sur un jeton SAML

  • Choix de l’authentification pour les environnements LDAP

  • Planification des zones des applications Web

  • Architecture des fournisseurs basés sur jetons SAML

Méthodes d’authentification prises en charge

SharePoint Server 2010 prend en charge les méthodes d’authentification qui étaient fournies avec les versions précédentes et introduit également l’authentification basée sur les jetons et sur le langage SAML (Security Assertion Markup Language) en guise d’option. Le tableau suivant répertorie les méthodes d’authentification prises en charge.

Méthode Exemples Remarques

Authentification Windows

  • NTLM

  • Kerberos

  • Anonyme

  • De base

  • Digest

À l’heure actuelle, l’authentification par certificat Windows n’est pas prise en charge.

Authentification par formulaire

  • LDAP (Lightweight Directory Access Protocol)

  • Base de données SQL ou autre

  • Fournisseurs d’appartenances et de rôles personnalisés ou tiers

Authentification basée sur un jeton SAML

  • Services AD FS (Active Directory Federation Services) 2.0

  • Fournisseur d’identités tiers

  • LDAP (Lightweight Directory Access Protocol)

Prise en charge uniquement avec SAML 1.1 qui utilise le profil WS-Federation Passive.

Modes d’authentification, classique ou par revendications

SharePoint Server 2010 introduit l’authentification basée sur les revendications, qui repose sur Windows Identity Foundation (WIF). Vous pouvez utiliser n’importe laquelle des méthodes d’authentification prises en charge avec l’authentification basée sur les revendications ou utiliser le mode d’authentification classique, qui prend en charge l’authentification Windows.

Lorsque vous créez une application Web, vous sélectionnez l’un des deux modes d’authentification disponibles pour l’application Web (mode classique ou basé sur les revendications).

Authentification par revendication ou authentification en mode classique

Si vous sélectionnez le mode classique, vous pouvez implémenter l’authentification Windows ; dans ce cas, les comptes d’utilisateurs sont traités par SharePoint Server 2010 comme des comptes AD DS (Active Directory Domain Services).

Si vous sélectionnez l’authentification basée sur les revendications, SharePoint Server 2010 modifie automatiquement tous les comptes d’utilisateurs en identités de revendications, ce qui génère un 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’appartenance (membership users) basée sur formulaires sont convertis en revendications d’authentification basée sur formulaires. Les revendications incluses dans les jetons SAML peuvent être utilisées par SharePoint Server 2010. Par ailleurs, les développeurs et administrateurs SharePoint peuvent augmenter les jetons utilisateur avec des revendications supplémentaires. Par exemple, les comptes d’utilisateurs Windows et les comptes d’utilisateurs basés sur formulaires peuvent être augmentés avec des revendications supplémentaires utilisées par SharePoint Server 2010.

Le graphique suivant résume la prise en charge des types d’authentification pour chaque mode d’authentification.

Type Mode d’authentification classique Authentification par revendications

Windows

  • NTLM

  • Kerberos

  • Anonyme

  • De base

  • Digest

Oui

Oui

Authentification par formulaire

  • LDAP

  • Base de données SQL ou autre

  • Fournisseurs d’appartenances et de rôles personnalisés ou tiers

Non

Oui

Authentification basée sur un jeton SAML

  • AD FS 2.0

  • Windows Live ID

  • Fournisseur d’identités tiers

  • LDAP

Non

Oui

Une batterie SharePoint Server 2010 peut inclure une combinaison d’applications Web qui utilisent les deux modes. Les services ne font pas de distinction entre les comptes d’utilisateurs qui sont des comptes Windows traditionnels et les comptes de revendications Windows. Par conséquent, un utilisateur qui appartient à des sites configurés de façon à utiliser une combinaison de modes d’authentification recevra des résultats de recherche incluant des résultats provenant de tous les sites auquel l’utilisateur a accès, quel que soit le mode configuré pour les applications Web. L’utilisateur n’est pas interprété comme étant deux comptes d’utilisateurs différents car les services et applications de service utilisent des identités de revendications pour les communications inter-batterie, quel que soit le mode sélectionné pour les applications Web et les utilisateurs.

En revanche, les utilisateurs qui appartiennent à plusieurs référentiels d’utilisateurs reconnus par des applications Web SharePoint Server sont traités comme des comptes d’utilisateurs distincts, selon l’identité utilisée pour ouvrir la session.

Les conseils suivants vous aideront à décider du mode à sélectionner :

  • Pour les nouvelles implémentations de SharePoint Server 2010, utilisez l’authentification basée sur les revendications. Avec cette option, tous les types d’authentification pris en charge sont disponibles pour les applications Web. Il n’existe aucune raison concrète de sélectionner le mode d’authentification classique pour les nouveaux déploiements, même si votre environnement comprend uniquement des comptes Windows. L’authentification Windows est implémentée de la même manière, quel que soit le mode sélectionné. Aucune étape supplémentaire n’est nécessaire à l’implémentation de l’authentification Windows lorsque vous utilisez le mode d’authentification basée sur les revendications.

  • Si vous mettez à niveau une solution de version antérieure vers SharePoint Server 2010 et que la solution comprend uniquement des comptes Windows, vous pouvez utiliser le mode d’authentification classique. Cela vous permet d’utiliser la même conception pour les zones et les URL.

  • Si vous mettez à niveau une solution qui requiert l’authentification basée sur les formulaires, la seule option consiste à effectuer une mise à niveau vers l’authentification basée sur les revendications.

Si vous effectuez une mise à niveau à partir d’une version antérieure vers SharePoint Server 2010 et que vous sélectionnez l’authentification basée sur les revendications, prenez note des considérations suivantes :

  • Vous devrez peut-être modifier le code personnalisé. Les composants WebPart ou autre code personnalisé qui utilisent ou reposent sur des identités Windows devront être mis à jour. Si le code personnalisé utilise des identités Windows, utilisez le mode d’authentification classique jusqu’à ce que le code ait été mis à jour.

  • La migration de nombreux utilisateurs Windows vers les identités de revendications prend du temps. Lorsque vous modifiez une application Web du mode classique au mode basé sur les revendications durant le processus de mise à niveau, vous devez utiliser Windows PowerShell pour convertir les identités Windows en identités de revendications. Ce processus peut être long. Assurez-vous de disposer de suffisamment de temps lors du processus de mise à niveau pour effectuer cette tâche.

  • Les alertes de recherche ne sont pas prises en charge actuellement avec l’authentification basée sur les revendications.

L’authentification basée sur les revendications repose sur WIF. WIF 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. Pour plus d’informations sur l’authentification basée sur les revendications, voir les ressources suivantes :

Il n’est pas nécessaire d’être architecte de revendications pour utiliser l’authentification basée sur les revendications dans SharePoint Server 2010. Toutefois, l’implémentation de l’authentification basée sur les jetons SAML requiert une coordination avec les administrateurs de votre environnement basé sur les revendications, comme décrit plus loin dans cet article.

Mise en œuvre de l’authentification Windows

Le processus d’implémentation des méthodes d’authentification Windows est similaire pour les deux modes d’authentification (classique et basé sur les revendications). Le fait de choisir l’authentification basée sur les revendications pour une application Web n’accroît pas la complexité de l’implémentation des méthodes d’authentification Windows. Cette section résume le processus pour chaque méthode.

Authentification Windows intégrée — Kerberos et NTLM

Le protocole Kerberos et NTLM sont des méthodes d’authentification Windows intégrée qui permettent aux clients de s’authentifier de façon transparente sans être invités à fournir d’informations d’identification. Les utilisateurs qui accèdent à des sites SharePoint à partir de l’Explorateur Windows s’authentifieront à l’aide des 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 accèdent à SharePoint Server en mode d’authentification Windows intégrée tenteront de s’authentifier à l’aide des informations d’identification du thread en cours d’exécution, qui correspondent à l’identité du processus par défaut.

NTLM est la forme d’authentification Windows la plus simple à implémenter. Il vous suffit de sélectionner cette option lors de la création d’une application Web.

Le protocole Kerberos est un protocole sécurisé qui 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 dans les services AD DS avant d’installer SharePoint Server 2010.

Les étapes suivantes récapitulent le processus de configuration de l’authentification Kerberos :

  1. Configurer l’authentification Kerberos pour les communications SQL en créant des noms de principaux du service dans les services AD DS pour le compte de service SQL Server.

  2. Créez des noms de principaux du service pour les applications Web qui utiliseront l’authentification Kerberos.

  3. Installez la batterie SharePoint Server 2010.

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

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

Pour plus d’informations, voir Planifier l’authentification Kerberos (SharePoint Server 2010).

En outre, pour les applications Web d’authentification par revendications, le service d’émission de jetons Revendications vers Windows doit être configuré pour la délégation contrainte. La délégation contrainte doit convertir l’émission de jetons Revendications vers Windows. Pour les environnements avec plusieurs forêts, une approbation bidirectionnelle entre forêts est indispensable pour utiliser le service d’émission de jetons Revendications vers Windows. Pour plus d’informations sur la configuration de ce service, voir Configurer l’authentification Kerberos pour le service d’émission de jetons Revendications vers Windows (SharePoint Server 2010).

L’authentification Kerberos autorise la délégation des informations d’identification clientes afin d’accéder aux systèmes de données principaux, ce qui nécessite une configuration supplémentaire en fonction du scénario. Des exemples sont fournis dans le tableau suivant.

Scénario Configuration supplémentaire

Délégation de l’identité d’un client à un serveur principal.

Affichage de flux RSS à du contenu authentifié.

Configurer la délégation contrainte Kerberos pour des ordinateurs et des comptes de service.

Délégation d’identité pour Microsoft SQL Server Reporting Services (SSRS)

Configurer des noms de principaux du service pour des comptes SQL Server Reporting Services.

Configurer la délégation pour SQL Server Reporting Services.

Délégation d’identité pour Excel Services dans SharePoint

Configurer la délégation contrainte pour des serveurs Excel Services.

Configurer la délégation contrainte pour le compte de service Excel Services.

Pour plus d’informations sur la façon de configurer l’authentification Kerberos, notamment sur les étapes de configuration pour les scénarios courants, voir Configuration de l’authentification Kerberos pour les produits et technologies Microsoft SharePoint 2010 (livre blanc) (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=197178&clcid=0x40C).

Digest et De base

L’implémentation de l’authentification Digest et De base nécessite de configurer ces méthodes d’authentification directement dans les services Internet (IIS, Internet Information Services).

Mise en œuvre de l’authentification par formulaire

L’authentification basée sur les formulaires est un système de gestion des identités basée sur l’authentification par fournisseur de rôles et d’appartenances ASP.NET. Dans SharePoint Server 2010, l’authentification basée sur les formulaires est disponible uniquement lorsque vous utilisez l’authentification basée sur les revendications.

L’authentification basée sur les formulaires peut être utilisée contre des informations d’identification stockées dans les services AD DS, dans une base de données telle qu’une base de données SQL Server ou dans 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 autorise l’authentification de l’utilisateur en fonction de la validation de l’entrée des informations d’identification à partir d’un formulaire d’ouverture de session. Les demandes non authentifiées sont redirigées vers une page d’ouverture de session, dans laquelle l’utilisateur doit fournir des informations d’identification valides et envoyer le formulaire. Si la demande peut être authentifiée, le système émet un cookie contenant une clé pour rétablir l’identité pour les demandes suivantes.

Pour utiliser l’authentification basée sur les formulaires pour authentifier des utilisateurs par rapport à 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. L’inscription du gestionnaire de rôles est une nouvelle exigence dans SharePoint Server 2010. Dans la version précédente, elle était facultative. SharePoint Server 2010 utilise l’interface standard du gestionnaire de rôles ASP.NET pour recueillir des informations de groupe concernant l’utilisateur actuel. Chaque rôle ASP.NET est traité comme un groupe de domaines par le processus d’autorisation dans SharePoint Server 2010. L’inscription des gestionnaires de rôles dans le fichier Web.config s’effectue de la même manière que celle des 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 de SharePoint, 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 plus d’informations sur la façon de configurer l’authentification basée sur les formulaires, voir les ressources suivantes :

Implémentation de l’authentification basée sur les jetons SAML

L’authentification basée sur les jetons SAML 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. AD FS 2.0 est un exemple d’environnement basé sur les revendications.

Un environnement basé sur les revendications comprend un service de jetons de sécurité de fournisseur d’identité (IP-STS, Identity Provider Security Token Service). Le service IP-STS émet des jetons SAML pour le compte des utilisateurs qui sont inclus dans l’annuaire d’utilisateurs associé. Les jetons peuvent inclure une quantité quelconque de revendications relatives à un utilisateur, telles qu’un nom d’utilisateur et les groupes auxquels l’utilisateur appartient.

SharePoint Server 2010 tire parti des revendications incluses dans les jetons fournis par un service IP-STS pour autoriser les utilisateurs. Dans les environnements à revendications, une application qui accepte des jetons SAML porte le nom de partie de confiance STS (RP-STS, Relying Party STS). Une application partie de confiance reçoit le jeton SAML et utilise les revendications qui s’y trouvent pour décider s’il faut accorder au client l’accès à la ressource demandée. Dans Produits SharePoint 2010, chaque application Web configurée de façon à 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.

L’implémentation de l’authentification basée sur les jetons SAML avec Produits SharePoint 2010 implique les processus suivants qui requièrent une planification approfondie :

  1. Exportez le certificat de signature de jetons à partir du service IP-STS. Ce certificat porte le nom d’ImportTrustCertificate. Copiez le certificat sur un ordinateur serveur dans la batterie SharePoint Server 2010.

  2. Définissez la revendication qui sera utilisée comme identificateur unique de l’utilisateur. Elle porte le nom de revendication d’identité. De nombreux exemples de ce processus utilisent le nom de courrier électronique de l’utilisateur en guise d’identificateur utilisateur. Collaborez avec l’administrateur du service IP-STS afin de déterminer l’identificateur correct, car seul le propriétaire du service IP-STS sait quelle valeur dans le jeton sera toujours unique à chaque utilisateur. L’identification de l’identificateur unique de l’utilisateur fait partie du processus de mappage de revendications. La création des mappages de revendications s’effectue à l’aide de Windows PowerShell.

  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 2010. Les rôles des utilisateurs sont un exemple de revendication pouvant être utilisée pour accorder des autorisations aux ressources dans la batterie SharePoint Server 2010. Toutes les revendications d’un jeton entrant qui ne possèdent pas de mappage sont rejetées.

  4. Créez un fournisseur d’authentification à l’aide de Windows PowerShell afin d’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 des applications Web SharePoint supplémentaires. 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. Créez une application Web SharePoint et configurez-la de façon à utiliser le fournisseur d’authentification nouvellement créé. Celui-ci apparaît comme une option dans l’Administration centrale lorsque le mode de revendications est sélectionné pour l’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 de collaborer avec l’administrateur de votre environnement de revendications interne afin d’établir une relation d’approbation de votre service IP-STS interne vers le service STS partenaire. Cette approche ne nécessite pas l’ajout d’un fournisseur d’authentification supplémentaire à votre batterie SharePoint Server 2010. Elle permet également à votre administrateur de revendications de gérer l’ensemble de l’environnement de revendications.

Notes

Si vous utilisez l’authentification basée sur les jetons SAML avec les services AD FS sur une batterie SharePoint Server 2010 qui possède plusieurs serveurs Web dans une configuration à équilibrage de la charge, il se peut que vous constatiez un impact sur les performances et la fonctionnalité des visualisations de pages Web clientes. Lorsque les services AD FS fournissent le jeton d’authentification au client, ce jeton est soumis à SharePoint Server 2010 pour chaque élément de page à l’autorisation restreinte. Si la solution d’équilibrage de la charge n’utilise pas l’affinité, chaque élément sécurisé est authentifié auprès de plusieurs serveurs SharePoint Server 2010, ce qui peut entraîner un rejet du jeton. Une fois le jeton rejeté, SharePoint Server 2010 redirige le client afin qu’il se réauthentifie auprès du serveur AD FS. Après cela, un serveur AD FS peut rejeter plusieurs demandes effectuées durant un court laps de temps. Ce comportement est inhérent au produit et destiné à assurer une protection contre les attaques par déni de service. Si vous observez une dégradation des performances ou si des pages ne se chargent pas complètement, configurez l’équilibrage de la charge réseau avec l’affinité unique, de manière à isoler les demandes de jetons SAML sur un serveur Web unique.

Pour plus d’informations sur la façon de configurer l’authentification basée sur les jetons SAML, voir les ressources suivantes :

Choix de l’authentification pour les environnements LDAP

Il est possible d’implémenter des environnements LDAP avec l’authentification basée sur des formulaires ou l’authentification basée sur les jetons SAML. Nous vous recommandons d’utiliser l’authentification basée sur des formulaires car elle est mois complexe. Néanmoins, si l’environnement prend en charge WS-Federation 1.1 et SAML Token 1.1, il est conseillé de recourir à l’authentification basée sur les jetons SAML La synchronisation des profils n’est pas prise en charge avec les fournisseurs LDAP qui ne sont pas associés à ADFS 2.0.

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 applications Web. Chaque application Web peut inclure jusqu’à cinq zones. Lors de la création d’une application Web, la zone par défaut est créée. Il est possible de créer des zones supplémentaires en étendant l’application Web et en sélectionnant l’un des noms de zones restants : intranet, extranet, Internet ou personnalisé.

Dans les versions précédentes, les zones servaient à implémenter différents types d’authentification pour les utilisateurs provenant de différents réseaux ou fournisseurs d’authentification. Dans la version actuelle, l’authentification par revendications permet d’implémenter plusieurs types d’authentification sur la même zone.

Le plan des zones dépendra du mode sélectionné pour une application Web, parmi les suivants :

  • Mode classique — Semblable aux versions précédentes ; un seul type d’authentification peut être implémenté par zone. Toutefois, dans la version actuelle, seule l’authentification Windows peut être implémentée lorsque le mode classique est sélectionné. Par conséquent, il est possible d’utiliser plusieurs zones uniquement pour implémenter plusieurs types d’authentification Windows ou pour implémenter le même type d’authentification Windows contre différents magasins Active Directory.

  • Authentification basée sur les revendications — Plusieurs fournisseurs d’authentification peuvent être implémentés sur une même zone. Il est également possible d’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 plus d’un type d’authentification, nous vous recommandons d’implémenter plusieurs types d’authentification sur la zone par défaut. Cela génère la même URL pour tous les utilisateurs.

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

  • Une seule instance d’authentification basée sur les formulaires peut être implémentée sur une zone.

  • L’Administration centrale vous permet d’utiliser l’authentification Windows intégrée et l’authentification de base simultanément. 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 comme options lors de la création d’une application Web ou d’une zone. Il est possible de 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.

Types d’authentification multiples sur une zone

sur Sur le diagramme, les utilisateurs de différents magasins d’annuaires accèdent au site Web partenaire à l’aide de la même URL. Une case en pointillé entourant 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. Pour plus d’informations sur cet exemple de conception, voir Exemple de conception : déploiement en entreprise (SharePoint Server 2010).

Planification de l’analyse du contenu

Le composant d’analyse requiert l’accès au contenu avec NTLM. 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émentation de plusieurs zones

Si vous souhaitez implémenter plusieurs zones pour les applications Web, utilisez 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 la zone qui est créée lorsque vous créez initialement 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 site IIS et domaine 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 montre plusieurs zones implémentées de façon à gérer plusieurs types d’authentification pour un site de collaboration partenaire.

Une zone pour chaque 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. Pour plus d’informations sur cet exemple de conception, voir Exemple de conception : déploiement en entreprise (SharePoint Server 2010).

Architecture des fournisseurs basés sur jetons SAML

L’architecture d’implémentation des fournisseurs basés sur jetons SAML comprend 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 par revendications. On l’utilise également pour les méthodes d’authentification implémentées pour des applications Web qui utilisent l’authentification par revendications, y compris l’authentification Windows, l’authentification basée sur les formulaires et l’authentification basée sur les jetons SAML. Vous devez configurer le service d’émission de jeton de sécurité lors du processus de déploiement. Pour plus d’informations, voir Configurer le service d’émission de jeton de sécurité (SharePoint Server 2010).

Certificat de signature de jetons (ImportTrustCertificate)   Il s’agit du certificat exporté à partir d’un service IP-STS. Le certificat est copié sur un serveur de la batterie. Une fois que vous avez utilisé ce certificat pour créer un SPTrustedIdentityTokenIssuer, vous ne pouvez plus l’utiliser pour en créer un autre. Si vous souhaitez utiliser le certificat pour créer un SPTrustedIdentityTokenIssuer différent, vous devez tout d’abord supprimer le SPTrustedIdentityTokenIssuer existant. Avant cela, vous devez le dissocier de toute application Web susceptible 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 à chaque utilisateur. La revendication d’identité est créée en tant que mappage de revendications ordinaire lors du processus de 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 de revendications supplémentaires tirées d’un ticket SAML qui décrivent les utilisateurs. Il peut s’agir de rôles des 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. Lorsque vous créez un fournisseur 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. Des revendications supplémentaires peuvent être ajoutées après la création du 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 le 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émentaire. Vous ne pouvez associer un certificat de signature de jetons d’un service STS qu’à un seul SPTrustedIdentityTokenIssuer. Toutefois, après avoir créé le SPTrustedIdentityTokenIssuer, 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 2010, chaque application Web configurée de façon à utiliser un fournisseur SAML est ajouté 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 illustre l’architecture de revendications de Produits SharePoint 2010.

Composants d’authentification par revendication de SharePoint

La création de l’objet SPTrustedIdentityTokenIssuer s’effectue avec plusieurs paramètres. Le diagramme suivant illustre les principaux paramètres.

Architecture SPTrustedIdentityTokenIssuer

Comme indiqué dans le diagramme, un SPTrustedIdentityTokenIssuer ne peut inclure qu’une seule revendication d’identité, un paramètre SignInURL et un paramètre Wreply. Toutefois, il peut inclure plusieurs domaines et plusieurs mappages de revendications. Le paramètre SignInURL spécifie l’URL vers laquelle rediriger une demande d’utilisateur afin de s’authentifier auprès du service IP-STS. Certains serveurs IP-STS requièrent le paramètre Wreply, qui prend la valeur true ou false et est false par défaut. Utilisez le paramètre Wreply uniquement si le service IP-STS l’exige.