Architecture et scénarios de revendications pour les développeurs SharePoint 2010

Résumé : découvrez comment l’authentification basée sur les revendications dans Microsoft SharePoint 2010 vous permet de prendre en charge des scénarios avancés qui nécessitent un développement personnalisé.

Dernière modification : mercredi 5 septembre 2012

S’applique à : Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Dans cet article
Vue d’ensemble des scénarios avancés d’authentification basée sur les revendications
Création de pages de connexion personnalisées utilisées par la fonctionnalité d’authentification basée sur les formulaires
Personnalisation des pages de sélection de l’authentification afin de fournir des informations supplémentaires
Ajout de revendications basées sur le contexte au jeton de revendications de l’utilisateur
Authentification depuis une application cliente en suivant le modèle d’authentification passive
Migration de modèles d’authentification ISAPI vers SharePoint 2010
Prise en charge des jetons de revendications émis par SharePoint 2010 dans les services Web compatibles avec les revendications
Activation de l’authentification haute sécurité (2FA) dans SharePoint 2010
Conclusion
À propos de l’auteur
Ressources supplémentaires

Auteur :  Javier Dalzell, Schakra Inc

Contenu

• Vue d’ensemble des scénarios avancés d’authentification basée sur les revendications

• Création de pages de connexion personnalisées utilisées par la fonctionnalité d’authentification basée sur les formulaires

• Personnalisation des pages de sélection de l’authentification afin de fournir des informations supplémentaires

• Ajout de revendications basées sur le contexte au jeton de revendications de l’utilisateur

• Authentification depuis une application cliente en suivant le modèle d’authentification passive

• Migration de modèles d’authentification ISAPI vers SharePoint 2010

• Prise en charge des jetons de revendications émis par SharePoint 2010 dans les services Web compatibles avec les revendications

• Activation de l’authentification haute sécurité (2FA) dans SharePoint 2010

• Conclusion

• À propos de l’auteur

• Ressources supplémentaires

Vue d’ensemble des scénarios avancés d’authentification basée sur les revendications

L’un des aspects importants de l’authentification basée sur les revendications dans Microsoft SharePoint 2010 est le fait que les développeurs de solutions peuvent utiliser sa puissance par programme afin d’activer des scénarios d’authentification plus avancés.

Cet article décrit différents scénarios qui impliquent les tâches suivantes :

• création de pages de connexion personnalisées ;

• personnalisation de la page de sélection d’authentification ;

• ajout de revendications basées sur le contexte au jeton de revendications de l’utilisateur ;

• authentification depuis une application cliente ;

• migration de modèles d’authentification basés sur ISAPI (Internet Server API) vers SharePoint 2010 ;

• prise en charge du jeton de revendications émis par SharePoint 2010 dans les services Web compatibles avec les revendications ;

• activation de l’authentification haute sécurité, y compris l’authentification à deux facteurs (2FA) dans SharePoint 2010.

Cet article suppose que vous connaissez l’authentification basée sur les revendications dans SharePoint 2010.

Pour plus d’informations sur l’authentification basée sur les revendications, voir Conseils relatifs aux revendications 1 : authentification basée sur les revendications dans SharePoint 2010.

Bien que cet article ne contienne pas de procédure pas à pas ou d’exemple de code, il peut vous aider à comprendre les concepts sous-jacents à chacune des tâches de la liste précédente. Pour obtenir des procédures pas à pas avec des exemples de code, voir Revendications et sécurité : Articles techniques.

Présentation des flux d’authentification dans SharePoint 2010

Lorsque vous configurez une application Web SharePoint 2010 en mode de revendications, différentes options d’authentification sont disponibles. Ces options déterminent le flux du processus d’authentification. Pour en savoir plus sur les options d’authentification, voir Autorisation et authentification.

La Figure 1 montre les étapes du processus d’authentification. Elle explique, dans l’ordre, les différents itinéraires que peut suivre le flux de processus en fonction des options d’authentification disponibles dans SharePoint 2010.

Figure 1. Architecture de haut niveau du processus d’authentification basée sur les revendications

Étapes du processus d’authentification

1. Le client demande une ressource SharePoint.

2. Dans le cadre du pipeline de demande, si la demande n’est pas authentifiée, les composants d’authentification acheminent la demande en fonction des paramètres d’authentification de cette zone.

3. La demande est ensuite traitée par les composants d’authentification. Lorsque plusieurs méthodes d’authentification sont configurées pour la zone en question, la page de sélection d’authentification permet à l’utilisateur de choisir la méthode authentification. Si une seule méthode d’authentification est spécifiée, la demande est traitée directement par la méthode d’authentification spécifiée.

4. L’utilisateur est authentifié par le fournisseur d’identité.

5. Si l’authentification réussit, le service d’émission de jetons de sécurité (STS) de SharePoint génère un jeton basé sur les revendications pour l’utilisateur avec les informations délivrées par le fournisseur d’identité. Si des fournisseurs de revendications supplémentaires sont configurés, le service STS augmente le jeton de l’utilisateur avec les revendications données par le fournisseur de revendications. Pour plus d’informations sur les fournisseurs de revendications, voir Conseils relatifs aux revendications 2 : authentification basée sur les revendications dans SharePoint 2010.

6. Le jeton basé sur les revendications de l’utilisateur est renvoyé aux composants d’authentification.

7. Les composants d’authentification redirigent la demande vers l’adresse de la ressource, avec le jeton basé sur les revendications émis pour l’utilisateur.

8. Le reste du pipeline de demande est exécuté et une réponse est renvoyée au demandeur (client). Dans le cadre du pipeline de demande, l’autorisation est terminée.

Comme mentionné plus haut, le flux du processus d’authentification est défini par les options que vous sélectionnez durant la configuration de la zone. Les figures suivantes illustrent comment ces options définissent le flux d’authentification.

Figure 2. Flux d’authentification

Chacun des types d’authentification suit un pipeline spécifique. Les Figures 3, 4 et 5 peuvent vous aider à comprendre le fonctionnement de chaque type d’authentification.

Pipeline d’authentification Windows

Lorsque l’authentification Windows est l’unique type d’authentification activé dans une zone, les utilisateurs sont authentifiés silencieusement à l’aide de NTLM ou Negotiate (protocole Kerberos) durant le pipeline de demande. Une fois l’utilisateur authentifié, un jeton basé sur les revendications est demandé au service STS SharePoint et une identité de revendication est créée. Au-delà de ce stade, SharePoint continue de traiter la demande, notamment d’effectuer les contrôles d’accès adéquats.

Figure 3. Flux d’authentification Windows

Lorsque le type d’authentification Windows et un ou plusieurs autres types d’authentification sont activés, l’utilisateur est redirigé vers la page de sélection d’authentification. Si l’utilisateur sélectionne l’option qui fait appel à l’authentification Windows, la demande utilisateur est redirigée vers la page d’authentification Windows, qui est silencieuse (aucune autre interface utilisateur n’est présentée à l’utilisateur pour lui signaler qu’il est redirigé, à moins que l’authentification de base ne soit configurée). Dans la page d’authentification Windows, lorsque l’utilisateur est authentifié, un jeton basé sur les revendications est demandé et l’utilisateur est renvoyé vers la ressource demandée. Étant donné que la demande contient un jeton basé sur les revendications émis par le service STS SharePoint, une identité de revendication est créée et le processus de demande continue.

La Figure 4 illustre le flux du processus d’authentification Windows et répertorie les étapes d’authentification dans l’ordre.

Figure 4. Processus d’authentification Windows

Présentation du processus d’authentification Windows

1. L’utilisateur demande une ressource SharePoint 2010.

2. L’authentification utilisateur (demande NTLM/négociation Kerberos) se produit.

3. La demande de jeton basé sur les revendications est envoyée au service STS SharePoint 2010.

4. Le service STS SharePoint obtient les groupes de sécurité de l’utilisateur à partir du jeton Windows et les ajoute dans le jeton en tant que revendications utilisateur.

   Notes

   Le SID de groupe est l’élément ajouté dans le jeton de revendication.

5. Le service STS SharePoint obtient des revendications supplémentaires pour l’utilisateur (si un fournisseur de revendications supplémentaire est enregistré pour cette application/zone Web).

6. Le jeton basé sur les revendications est émis.

7. La demande est traitée par le reste des composants du pipeline.

8. La réponse est renvoyée à l’utilisateur.

Pipeline d’authentification basée sur les formulaires

Dans le cas de l’authentification basée sur les formulaires, l’utilisateur est redirigé vers la page de connexion basée sur les formulaires de SharePoint. Si des types d’authentification supplémentaires sont configurés, l’utilisateur est redirigé tout d’abord vers la page de sélection d’authentification, puis vers la page de connexion s’il sélectionne l’option liée au type d’authentification basée sur les formulaires.

La page de connexion basée sur les formulaires de SharePoint recueille les informations d’identification de l’utilisateur, qui sont ensuite envoyées au service STS SharePoint 2010. Celui-ci appelle le fournisseur d’appartenances associé à cette application Web afin de valider les informations d’identification de l’utilisateur. Si cette opération réussit, le service STS extrait les rôles auxquels appartient l’utilisateur et les ajoute comme revendications dans le jeton basé sur les revendications qui est renvoyé à la page de connexion.

À partir de la page de connexion, une fois le jeton basé sur les revendications émis, l’utilisateur est renvoyé vers la ressource demandée et le processus continue de la même façon que dans l’authentification Windows.

Figure 5. Processus d’authentification basée sur les formulaires

Présentation du processus d’authentification basée sur les formulaires

1. L’utilisateur demande une ressource SharePoint 2010.

2. SharePoint redirige l’utilisateur vers la page de connexion d’authentification basée sur les formulaires.

3. Le nom d’utilisateur et le mot de passe sont obtenus de l’utilisateur et envoyés vers le service STS SharePoint 2010.

4. Le service STS valide les informations d’identification de l’utilisateur avec le fournisseur d’appartenances et, si la validation réussit, il demande tous les rôles auxquels l’utilisateur appartient et ajoute ces revendications au jeton de l’utilisateur.

5. Le service STS SharePoint obtient des revendications supplémentaires pour l’utilisateur (si un fournisseur de revendications supplémentaire est enregistré pour cette application/zone Web).

6. Le jeton basé sur les revendications est émis.

7. La demande est traitée par le reste des composants du pipeline.

8. La réponse est renvoyée à l’utilisateur.

Pipeline d’authentification basée sur les jetons SAML

Avec l’implémentation par défaut des services de fédération Active Directory (AD FS, Active Directory Federation Services), lorsque l’authentification basée sur jeton SAML est activée dans les paramètres de zone, les utilisateurs sont redirigés vers une page d’authentification « silencieuse », qui les redirige ensuite vers la page de connexion, tel que spécifié dans le fournisseur d’authentification SAML. (toutefois, une autre configuration des services AD FS ou un autre fournisseur d’identité peut se comporter différemment). Pour en savoir plus sur les fournisseurs d’authentification SAML, voir la section « Implémentation de l’authentification basée sur les jetons SAML » dans Planifier des méthodes d’authentification (SharePoint Foundation 2010) sur Microsoft TechNet.

Si plusieurs fournisseurs d’authentification SAML ou des types d’authentification supplémentaires sont activés dans l’application Web, l’utilisateur est d’abord redirigé vers la page de sélection d’authentification, puis vers la page de connexion correspondante.

Une fois l’utilisateur authentifié par le fournisseur d’authentification, un jeton SAML est émis et l’utilisateur est redirigé vers la page d’authentification SharePoint 2010 basée sur jeton SAML. Le jeton SAML est ensuite inclus dans la demande avec la redirection. Ce processus porte le nom de « profils passifs ». Pour en savoir plus sur les profils passifs, voir le billet de blog intitulé Windows Identity Foundation 101’s : profil de demandeur passif WS-Federation (Partie 1 sur 2) (éventuellement en anglais).

La page d’authentification SAML demande un jeton basé sur les revendications au service STS interne de SharePoint 2010 ; la demande de jeton contient le jeton SAML d’origine qui a été émis par le fournisseur d’authentification. Le service STS SharePoint valide ensuite le jeton et émet le jeton utilisateur. Celui-ci est ensuite ajouté à la demande et la page d’authentification SAML redirige l’utilisateur vers la ressource d’origine. Après cela, le processus est identique à celui des autres flux d’authentification.

Figure 6. Processus d’authentification basée sur les revendications SAML

Présentation du processus d’authentification basée sur les revendications SAML

1. L’utilisateur demande une ressource SharePoint 2010.

2. SharePoint redirige l’utilisateur vers la page d’authentification SAML.

3. Selon la configuration du fournisseur de connexions approuvé, la demande est redirigée vers la page de connexion STS d’entreprise ou vers la page de connexion STS fédérée.

4. L’utilisateur fournit des informations d’identification et le service STS émet un jeton basé sur les revendications SAML.

5. Le service STS externe émet le jeton basé sur les revendications de l’utilisateur.

6. Un jeton basé sur les revendications pour l’utilisateur est demandé au service STS SharePoint et le jeton du service STS externe est utilisé comme preuve d’authentification.

7. Le service STS SharePoint obtient des revendications supplémentaires pour l’utilisateur (si un fournisseur de revendications supplémentaire est enregistré pour cette application ou zone Web).

8. Le service STS SharePoint émet le jeton basé sur les revendications.

9. La demande est traitée par le reste des composants du pipeline.

10. La réponse est renvoyée à l’utilisateur.

Le fournisseur d’identité est configuré dans SharePoint 2010 en tant que fournisseur de connexions approuvé. Selon le scénario, le fournisseur d’identité pourrait être le service STS d’entreprise ou un service STS externe dans le cas d’un fournisseur de connexions fédéré. En guise d’exemples de fournisseurs de connexions fédérés, on pourrait citer un service STS de partenaire (pour authentifier un utilisateur partenaire qui n’existe pas dans le référentiel d’utilisateurs de l’entreprise) ou un fournisseur d’authentification externe tel que Windows Live ID.

Bien qu’un fournisseur de connexions approuvé puisse être un fournisseur d’identité externe (service STS partenaire) dans SharePoint 2010, nous vous recommandons de fédérer l’authentification par le biais de votre service STS d’entreprise plutôt que d’établir l’approbation directement dans SharePoint 2010. Ensuite, configurez les approbations avec l’autre service STS dans le service STS d’entreprise. L’avantage est qu’il n’y a qu’un seul point d’entrée, où toutes les stratégies d’entreprise peuvent être appliquées. Autre avantage : la plupart des systèmes de gestion d’identités qui prennent en charge les revendications offrent de meilleurs outils pour la gestion des approbations avec le service STS fédéré. Si vous avez plusieurs batteries SharePoint 2010, le fait d’utiliser votre service STS d’entreprise comme « concentrateur de fournisseurs d’identité » vous permet de gérer les approbations en un seul endroit plutôt que plusieurs (dans chaque batterie SharePoint).

Maintenant que vous en savez davantage sur le flux du processus d’authentification, vous pouvez explorer différents scénarios d’authentification et les options à votre disposition pour gérer ces scénarios.

Les scénarios suivants représentent des cas typiques qui aident à illustrer des problèmes et fournissent des implémentations alternatives. Analysez votre scénario et, en fonction des caractéristiques de votre environnement, identifiez les solutions les plus adaptées.

Création de pages de connexion personnalisées utilisées par la fonctionnalité d’authentification basée sur les formulaires

SharePoint 2010 comprend une page de connexion par défaut utilisée par la fonctionnalité d’authentification basée sur les formulaires. Comme décrit dans les scénarios suivants, dans certains cas vous devez apporter des modifications à cette page de connexion par défaut.

Il existe de nombreux scénarios qui pourraient nécessiter des modifications de la page de connexion ; certains d’entre eux sont discutés dans les sections suivantes.

Gestion de l’authentification dans les scénarios d’extranet

Il existe plusieurs manières de gérer l’authentification dans les scénarios d’extranet. Dans la mesure du possible, il faut tirer parti de l’infrastructure réseau, par exemple utiliser un proxy inversé ou un service STS d’entreprise. Dans certaines situations cela n’est pas possible ; une alternative consiste alors à utiliser l’authentification basée sur les formulaires.

Lorsque l’authentification basée sur les formulaires est utilisée pour un extranet, il devient plus important de personnaliser la page de connexion afin de fournir davantage d’informations à l’utilisateur, un peu comme le contenu d’une page de connexion Microsoft Outlook Web Access.

Dans les scénarios extranet où des partenaires doivent avoir accès à des sites SharePoint, et lorsque le partenaire ne prend pas en charge l’authentification fédérée, l’authentification basée sur les formulaires est une alternative. De même que dans le scénario décrit ci-dessus, il est utile de personnaliser la page de connexion afin de fournir davantage d’informations à l’utilisateur.

Personnalisation des pages de connexion

Un scénario courant consiste à vouloir personnaliser la page de connexion conformément aux directives de l’entreprise relatives à l’interface utilisateur ou à vouloir ajouter des informations pour l’utilisateur, telles qu’une notice de confidentialité, des conditions d’utilisation et des instructions de connexion ou d’enregistrement de nouvel utilisateur.

Création d’une fonctionnalité « Mémoriser mes informations »

Dans certains cas, vous souhaiterez peut-être proposer aux utilisateurs une option de mémorisation du nom d’utilisateur et/ou du mot de passe, comme celles que l’on trouve par exemple dans les pages de connexion Windows Live ID.

Considérez ces cas supplémentaires dans lesquels la personnalisation de la page de connexion pourrait être utile :

• dépannage de l’authentification basée sur les formulaires ;

• ajout d’une logique d’enregistrement de nouvel utilisateur ;

• implémentation d’un mécanisme CAPTCHA ;

• ajout de notices de confidentialité ;

• implémentation d’une logique d’acceptation des conditions d’utilisation ;

• ajout de mécanismes anti-hameçonnage (par exemple, vérification d’image de site).

Pour plus d’informations sur la façon de créer une page de connexion personnalisée pour l’authentification basée sur les formulaires, voir Écriture d’une page de connexion de formulaire personnalisée pour SharePoint 2010 (éventuellement en anglais) et Comment créer une page de connexion personnalisée pour l’authentification basée sur les formulaires SharePoint 2010 (éventuellement en anglais).

Personnalisation des pages de sélection de l’authentification afin de fournir des informations supplémentaires

Comme expliqué précédemment, lorsque plusieurs fournisseurs d’authentification sont configurés dans une zone, les utilisateurs sont redirigés vers une page où ils peuvent sélectionner le fournisseur d’authentification à utiliser. Lorsque l’utilisateur accède à cette page, elle affiche uniquement un contrôle de sélection (voir la Figure 7).

Figure 7. Page de sélection de l’authentification par défaut

Dans certains cas, vous souhaiterez peut-être fournir davantage d’informations afin d’aider l’utilisateur à sélectionner le fournisseur d’authentification correct. Une autre amélioration que vous pouvez apporter consiste à ajouter la logique de découverte intelligente de domaine domestique, de sorte que les utilisateurs d’une plage d’adresses IP spécifique soient redirigés automatiquement vers le fournisseur d’identité correct. Il existe d’autres alternatives pour la découverte intelligente de domaine domestique ; la meilleure implémentation dépend de votre scénario et de la façon dont vous implémentez la découverte de domaine domestique.

Figure 8. Exemple de page de découverte de domaine domestique

Ajout de revendications basées sur le contexte au jeton de revendications de l’utilisateur

Les revendications contextuelles sont des assertions données à l’utilisateur en fonction d’une règle. Par exemple, une revendication contextuelle pourrait contenir l’emplacement du client, tel que le siège social de l’entreprise ou une filiale. Dans ce cas, la valeur de la revendication est calculée en fonction de l’endroit où le client se connecte. Ultérieurement, durant l’autorisation, ces informations pourraient être utilisées pour accorder ou refuser des autorisations pour une ressource.

Dans les scénarios à haute sécurité, ces revendications contextuelles peuvent fournir de précieuses informations pouvant servir à restreindre l’accès à des ressources.

Avec SharePoint 2010, ceci peut être accompli en :

• tirant parti de l’infrastructure de fournisseur de revendications durant l’augmentation des revendications ;

• implémentant les règles des revendications contextuelles dans le service STS d’entreprise (ou externe).

Nous vous recommandons d’implémenter les règles de revendications contextuelles dans le service STS d’entreprise pour les raisons suivantes :

• cela procure un point central pour la gestion des règles ;

• cela élimine la nécessité d’enregistrer et de gérer des fournisseurs de revendications dans plusieurs batteries SharePoint ;

• cela réduit le risque d’ouverture d’une faille de sécurité due à un fournisseur de revendications configuré de manière incorrecte.

Authentification depuis une application cliente en suivant le modèle d’authentification passive

Il existe des scénarios dans lesquels vous devrez peut-être créer une application cliente ou un complément pour le client Microsoft Office qui s’authentifie auprès de SharePoint 2010. Comme nous l’avons vu dans cet article, le modèle d’authentification SharePoint 2010 est basé dans le profil passif WS-Federation qui autorise les scénarios d’authentification par revendications pour des clients passifs tels qu’Internet Explorer. Microsoft Office utilise également ce modèle lors de l’authentification auprès de SharePoint 2010.

Pour authentifier un appel à SharePoint 2010, vous devez suivre le modèle utilisé par l’authentification passive. Pour en savoir plus sur la façon d’implémenter ce modèle, voir Authentification à distance dans SharePoint Online à l’aide de l’authentification basée sur les revendications. En guise d’alternative, vous pouvez utiliser le modèle décrit dans le billet de blog intitulé Utilisation du modèle objet client avec un site d’authentification basée sur les revendications dans SharePoint 2010 (éventuellement en anglais).

Migration de modèles d’authentification ISAPI vers SharePoint 2010

Dans les versions précédentes de SharePoint, des modèles d’authentification supplémentaires étaient implémentés dans SharePoint à l’aide du flux d’authentification basée sur les formulaires et de filtres ISAPI personnalisés qui géraient le processus d’authentification.

SharePoint 2010 implémente le pipeline intégré Internet Information Services 7, qui ne prend pas en charge les filtres ISAPI. De plus, lorsqu’une application Web est configurée pour l’authentification basée sur les formulaires, SharePoint 2010 effectue un appel explicite au fournisseur d’appartenances afin de valider les informations d’identification de l’utilisateur. Pour cette raison, certaines solutions d’authentification basée sur ISAPI ne fonctionnent pas dans SharePoint 2010.

L’authentification SharePoint 2010 basée sur les revendications procure un point d’extensibilité d’authentification en ayant recours à l’authentification basée sur les revendications SAML et au protocole WS-Federation.

Figure 9. Service d’émission de jeton de sécurité local

Comme l’illustre la Figure 9, l’authentification est effectuée en dehors de SharePoint 2010 dans le service STS de fournisseur d’identité. Le modèle d’authentification personnalisé peut être implémenté sur le fournisseur d’identité (ou devenir le fournisseur d’identité).

Pour plus d’informations sur l’authentification SAML, voir Configurer l’authentification à l’aide d’un jeton de sécurité SAML sur TechNet.

Prise en charge des jetons de revendications émis par SharePoint 2010 dans les services Web compatibles avec les revendications

L’une des principales exigences des scénarios de collaboration est la capacité à pouvoir partager des données. Dans la plupart des cas, les données que l’on souhaite utiliser lors de la collaboration proviennent d’autres systèmes. Vous pouvez tirer parti des avantages de l’authentification basée sur les revendications afin de déléguer l’identité de l’utilisateur actif au système où résident les informations. Pour que cela fonctionne, votre système doit être compatible avec les revendications et prendre en charge le protocole WS-Federation. Si votre système n’est pas compatible avec les revendications, vous pouvez créer une couche intermédiaire qui expose les données par le biais d’un service Web compatible avec les revendications.

Une fois les données exposées par le biais d’un service Web compatible avec les revendications, vous pouvez utiliser Microsoft Business Connectivity Services (BCS) dans SharePoint 2010 pour exposer les données dans SharePoint 2010. Pour en savoir plus sur la façon d’activer ce scénario, voir Consommation d’un service Web WCF compatible avec les revendications en tant que type de contenu externe SharePoint 2010 (éventuellement en anglais).

Activation de l’authentification haute sécurité (2FA) dans SharePoint 2010

Les modèles d’authentification avancée tels que l’authentification à deux facteurs (2FA) et l’authentification basée sur certificat client peuvent être implémentés dans SharePoint 2010 au moyen de l’authentification SAML. Des produits de gestion d’identité (comme les services AD FS 2.0) prennent en charge l’authentification haute sécurité, y compris 2FA. Dans ce scénario, comme dans le précédent, on utilise le service STS externe pour authentifier l’utilisateur par le biais de l’une des méthodes d’authentification prises en charge par le fournisseur.

Pour plus d’informations sur la configuration de SharePoint 2010 pour l’authentification basée sur certificat client, voir Configurer l’authentification du certificat client (SharePoint Server 2010) sur TechNet.

Pour en savoir plus sur la configuration de SharePoint 2010 avec l’authentification SAML, voir Configurer l’authentification à l’aide d’un jeton de sécurité SAML sur TechNet.

Pour plus d’informations sur la configuration des services AD FS 2.0, voir Guide de déploiement des services AD FS 2.0 (éventuellement en anglais) sur TechNet.

Conclusion

Comme expliqué dans cet article, vous pouvez tirer parti des avantages offerts par l’authentification basée sur les revendications afin d’activer différents scénarios d’authentification. Vous pouvez également effectuer des personnalisations afin d’améliorer l’expérience utilisateur lors de la collaboration par le biais de SharePoint 2010.

À propos de l’auteur

  Javier Dalzell travaille au sein de la division de solutions de produits chez Schakra Inc, une société qui propose des solutions pour SharePoint 2010, Office 365, l’informatique en nuage et le segment mobile. Avant de rejoindre Schakra, Javier a travaillé au sein de l’équipe Microsoft SharePoint 2010.

Ressources supplémentaires

Pour plus d’informations, voir les ressources suivantes :

• Blog de Steve Peschka : Share-n-dipity (éventuellement en anglais)

• Applets de commande pour la sécurité (SharePoint Foundation 2010)

• Blogs, centres de ressources et forums SharePoint sur la sécurité

• Conseils relatifs aux revendications 1 : authentification basée sur les revendications dans SharePoint 2010

• Procédure pas à pas pour les revendications : écriture de fournisseurs de revendications pour SharePoint 2010

• Procédure pas à pas sur les revendications : création de fournisseurs de revendications pour les fournisseurs de connexions approuvés pour SharePoint 2010

• Forms Authentication in SharePoint Products and Technologies (Part 1): Introduction

• Revendications entrantes : connexion à SharePoint

• Définitions des termes de l’identité basée sur des demandes

• Microsoft.SharePoint.Administration.Claims

• Planification, mise à niveau, migration, administration, configuration et installation

• 2 | Présentations vidéo sur la sécurité dans SharePoint 2010 (éventuellement en anglais)

• Blog de l’équipe de développement SharePoint (éventuellement en anglais)

• Centre de ressources sur la sécurité | SharePoint 2010 (éventuellement en anglais)

• Centre pour développeurs SharePoint