Pourquoi utiliser l’identité basée sur des revendications

Dernière modification : mercredi 16 février 2011

S’applique à : SharePoint Foundation 2010

L’identité basée sur des revendications est un modèle d’identité dans Microsoft SharePoint Foundation 2010 et Microsoft SharePoint Server 2010 qui comprend des fonctionnalités telles que l’authentification des utilisateurs sur des systèmes Windows et non-Windows, les types d’authentification multiples, l’authentification en temps réel renforcée, un jeu plus large de types principaux et la délégation de l’identité des utilisateurs entre les applications.

Systèmes d’authentification disparates

La plupart des applications d’entreprise ont besoin de certaines fonctionnalités de sécurité utilisateur de base. Au minimum, elles doivent authentifier leurs utilisateurs, et de nombreuses d’entre elles ont également besoin d’autoriser l’accès à certaines fonctionnalités afin que seuls les utilisateurs dotés de privilèges spécifiques puissent y accéder. Parfois, ces règles d’autorisation requièrent des attributs qui ne figurent pas dans les jetons de sécurité utilisateur existants ; par exemple, une liste de diffusion de Microsoft Exchange Server peut être utilisée comme principal pour sécuriser certains objets dans SharePoint Server 2010. Ces fonctionnalités de sécurité sont intégrées au système d’exploitation Windows et sont généralement faciles à intégrer à une application. En tirant parti de l’authentification Windows intégrée, vous n’avez pas besoin de créer votre propre protocole d’authentification ou de gérer une base de données utilisateur. En utilisant des listes de contrôle d’accès, l’emprunt d’identité et des fonctionnalités telles que des groupes, vous pouvez implémenter l’autorisation sans écrire beaucoup de code.

À l’image de Windows, SharePoint Foundation 2010 et SharePoint Server 2010 offrent un ensemble de fonctionnalités qui facilitent les tâches d’autorisation et, pour certains objets (tels que l’objet Site), cela se produit automatiquement en arrière-plan. Ce dispositif s’applique quels que soient le système d’exploitation ou l’application que vous utilisez. Il est presque toujours préférable d’effectuer une intégration étroite aux fonctionnalités de sécurité SharePoint prédéfinies que de réinventer ces fonctionnalités soi-même.

Toutefois, que se produit-il lorsque vous souhaitez atteindre des utilisateurs qui ne possèdent pas de comptes Windows ? Qu’en est-il des utilisateurs qui n’exécutent du tout Windows ? De plus en plus d’applications ont besoin de ce type d’accès à ces types d’utilisateurs, ce qui semble aller à l’encontre des contraintes de sécurité traditionnelles. L’identité basée sur des revendications est le nouveau modèle d’identité dans SharePoint Foundation 2010 et SharePoint Server 2010, conçu pour faciliter la résolution de ces problèmes, entre autres.

Sous Windows, le type d’information d’identification le plus couramment utilisé pour accéder à une application d’entreprise est le compte de domaine de l’utilisateur. Une application qui utilise l’authentification Windows intégrée reçoit un ticket Kerberos pour représenter un client, tandis qu’une application utilisant SSL (Secure Sockets Layer) peut recevoir un certificat X.509 pour le client. Un ticket Kerberos et un certificat X.509 sont des éléments très différents, et le code dans le système d’exploitation qui analyse, valide et finalement présente les données qu’ils contiennent est également très différent. Toutefois, si vous songez à ce que ces deux informations d’identification représentent réellement, vous constatez qu’elles ont beaucoup de points en commun.

Imaginons le scénario suivant. Alice est une utilisatrice qui souhaite accéder à un service d’achat à l’aide de son compte de domaine Windows. Son contrôleur de domaine l’authentifie et crée un ticket Kerberos contenant une série d’identificateurs de sécurité (SID). Ces SID représentent le compte d’utilisateur d’Alice et les groupes de domaines dont elle est membre. Les SID sont incorporés dans le ticket avec une signature du contrôleur de domaine. En termes d’identité, un « émetteur » (le contrôleur de domaine) donne à un bénéficiaire (Alice) un jeton de sécurité qui lui permet de prouver son identité. Le même concept s’applique lorsqu’Alice utilise un certificat à la place. Un certificat est simplement un autre type de jeton de sécurité. Dans ce cas, l’émetteur est une autorité de certification et le bénéficiaire est Alice. Le ticket Kerberos et le certificat sont, en substance, des affirmations signées par un émetteur au sujet d’un bénéficiaire. Il s’agit de deux façons différentes pour une autorité approuvée de se porter garante d’un de ses bénéficiaires. Chaque affirmation signée peut être assimilée à une collection de revendications. En d’autres termes, le contrôleur de domaine crée des revendications au sujet de l’identité d’Alice lorsqu’il signe la liste de SID dans son ticket. Chaque SID devient une revendication. L’autorité de certification crée des revendications au sujet de l’identité d’Alice lorsqu’elle signe ses nom et clé publique. Le nom et la clé publique sont des exemples de revendications dans le certificat.

L’objectif de ce nouveau modèle d’identité est d’extraire l’identité de manière à ce que vous soyez moins dépendant de types d’informations d’identification spécifiques, sans porter préjudice à la sécurité de votre application. En ajoutant du code dans le modèle d’identité dans SharePoint Server 2010, vous pouvez traiter l’identité de l’utilisateur délégué sans tickets Kerberos et également traiter les jetons SAML (Security Assertion Markup Language). Cela ouvre les portes de certaines architectures d’identité intéressantes, y compris l’identité fédérée.

Voir aussi

Concepts

Prise en main de la sécurité et du modèle d’identité basée sur des revendications

Vue d’ensemble et concepts de l’identité basée sur des revendications