Vue d’ensemble et concepts de l’identité basée sur des revendications
Dernière modification : jeudi 18 mars 2010
S’applique à : SharePoint Foundation 2010
Modèle d’identité basée sur des revendications
Lorsque vous créez des applications prenant en charge les revendications, l’utilisateur présente une identité à votre application sous la forme d’un jeu de revendications. Une revendication peut être le nom d’utilisateur, une autre une adresse de messagerie. En l’occurrence, l’idée est qu’un système d’identité externe est configuré pour donner à votre application toutes les informations dont elle a besoin sur l’utilisateur avec chaque demande, ainsi qu’une assurance cryptographique que les données d’identité reçues par votre application proviennent d’une source approuvée.
Sous ce modèle, l’authentification unique est beaucoup plus facile à obtenir et votre application n’est plus responsable des aspects suivants :
authentification des utilisateurs ;
stockage des comptes et mots de passe utilisateur ;
appel des annuaires d’entreprise pour rechercher les détails de l’identité de l’utilisateur ;
intégration aux systèmes d’identité à partir d’autres plateformes ou entreprises.
Sous ce modèle, votre application prend des décisions au sujet de l’identité en fonction des revendications fournies par l’utilisateur. Cela peut aller d’une simple personnalisation d’application avec le prénom de l’utilisateur à l’octroi à l’utilisateur de l’autorisation d’accéder à des fonctionnalités et à des ressources de plus grande valeur dans votre application.
Les sections suivantes, ainsi que quelques-unes des prochaines rubriques, présentent la terminologie et les concepts qui vous permettent de comprendre l’architecture de l’identité basée sur des revendications.
Identité
L’identité est un ensemble d’attributs qui décrivent un utilisateur, ou une autre entité, dans un système que vous souhaitez sécuriser.
Revendication
Vous pouvez assimiler une revendication à une information d’identité (telle que le nom, l’adresse de messagerie, l’âge ou l’appartenance à un rôle Ventes). Plus votre application reçoit de revendications, plus vous avez d’informations au sujet de l’utilisateur. Le terme utilisé est « revendication », et non le terme « attribut », couramment utilisé dans la description des annuaires d’entreprise, en raison de la méthode de remise. Dans ce modèle, votre application ne recherche pas d’attributs utilisateur dans un annuaire. À la place, l’utilisateur remet les revendications à votre application, qui les examine. Chaque revendication est créée par un émetteur et vous n’approuvez la revendication que dans la mesure où vous approuvez l’émetteur. Par exemple, vous approuvez davantage une revendication créée par le contrôleur de domaine de votre société qu’une revendication créée par l’utilisateur.
Jeton de sécurité
L’utilisateur remet un ensemble de revendications à votre application avec une demande. Dans un service Web, ces revendications sont véhiculées dans l’en-tête de sécurité de l’enveloppe SOAP. Dans une application Web basée sur le navigateur, les revendications parviennent par le biais d’une requête HTTP POST à partir du navigateur de l’utilisateur, et peuvent ultérieurement être mises en cache dans un cookie si une session est souhaitée. Indépendamment de leur mode d’arrivée, ces revendications doivent être sérialisées, et c’est là qu’entrent en jeu les jetons de sécurité. Un jeton de sécurité est un ensemble sérialisé de revendications signé numériquement par l’autorité émettrice. La signature est importante : elle vous donne l’assurance que l’utilisateur ne s’est pas contenté de préparer les revendications, puis de vous les envoyer. Dans les situations à faible niveau de sécurité où le chiffrement n’est pas nécessaire ou souhaité, vous pouvez utiliser des jetons non signés, mais ce scénario n’est pas décrit dans cette rubrique.
L’une des fonctionnalités fondamentales de Windows Identity Foundation (WIF) est la possibilité de créer et de lire les jetons de sécurité. WIF et Microsoft .NET Framework gèrent tout le travail de chiffrement et présentent à votre application un ensemble de revendications qu’elle peut lire.
Service d’émission de jeton de sécurité
Un service d’émission de jeton de sécurité est le dispositif qui génère, signe et émet les jetons de sécurité en fonction des protocoles interopérables présentés dans la section « Normes » de cette rubrique. L’implémentation de ces protocoles demande beaucoup de travail, mais WIF effectue la totalité de ce dernier à votre place, ce qui permet à une personne qui n’est pas experte en protocoles d’obtenir un service d’émission de jeton de sécurité opérationnel en fournissant très peu d’effort.
WIF permet de créer votre propre service d’émission de jeton de sécurité plus facilement. Il vous appartient de définir comment implémenter la logique, ou les règles, qui l’appliquent (souvent appelées stratégie de sécurité).
Autorité émettrice
Il existe de nombreux types différents d’autorités émettrices, allant des contrôleurs de domaine qui émettent des tickets Kerberos aux autorités de certification qui émettent des certificats X.509. Le type spécifique d’autorité présenté dans cette rubrique émet des jetons de sécurité qui contiennent des revendications. Cette autorité émettrice est une application Web ou un service Web qui émet des jetons de sécurité. Elle doit être en mesure d’émettre les revendications adéquates en fonction de la partie de confiance cible et de l’utilisateur qui effectue la demande, et peut être responsable de l’interaction avec les magasins d’utilisateurs pour rechercher les revendications et authentifier les utilisateurs.
Quelle que soit l’autorité émettrice que vous choisissez, elle joue un rôle central dans votre solution d’identité. Lorsque vous sous-traitez l’authentification en dehors de votre application à des revendications, vous transférez la responsabilité à cette autorité et lui demandez d’authentifier les utilisateurs en votre nom.
Partie de confiance
Lorsque vous créez une application qui repose sur des revendications, vous créez une application de partie de confiance. Les synonymes de « partie de confiance » sont « application prenant en charge les revendications » et « application basée sur les revendications ». Les applications Web et les services Web peuvent être des parties de confiance.
Une application de partie de confiance consomme des jetons émis par un service d’émission de jeton de sécurité et extrait les revendications des jetons en vue de les utiliser pour des tâches liées aux identités. Le service d’émission de jeton de sécurité prend en charge deux types d’application de partie de confiance : les applications Web ASP.NET et les services Web WCF (Windows Communication Foundation).
Normes
Pour que tout ce dispositif soit interopérable, plusieurs normes WS-* sont utilisées dans le scénario précédent. La stratégie est récupérée à l’aide de WS-MetadataExchange, et la stratégie elle-même est structurée en fonction de la spécification WS-Policy. Le service d’émission de jeton de sécurité expose les points de terminaison qui implémentent la spécification WS-Trust, laquelle explique comment demander et recevoir des jetons de sécurité. De nos jours, la plupart des services d’émission de jeton de sécurité émettent des jetons mis en forme avec SAML (Security Assertion Markup Language). SAML est un vocabulaire XML reconnu par la profession qui permet de représenter les revendications de façon interopérable ou, dans un environnement multiplateforme, de communiquer avec un service d’émission de jeton de sécurité sur une plateforme totalement différente et d’effectuer l’authentification unique dans toutes les applications, quelle que soit la plateforme.
Applications basées sur le navigateur
Les clients légers ne sont pas les seules entités qui peuvent utiliser le modèle d’identité basée sur des revendications. Les applications basées sur le navigateur (également appelées clients passifs) peuvent également l’utiliser. Le scénario suivant décrit ce fonctionnement.
L’utilisateur fait pointer un navigateur sur une application Web prenant en charge les revendications (application de partie de confiance). L’application Web redirige le navigateur vers le service d’émission de jeton de sécurité afin que l’utilisateur puisse être authentifié. Le service d’émission de jeton de sécurité est hébergé dans une application Web simple qui lit la demande entrante, authentifie l’utilisateur en utilisant des mécanismes HTTP standard, puis crée un jeton SAML et répond avec un fragment de code ECMAScript (JavaScript, JScript) ; ce dernier amène le navigateur à initier une requête HTTP POST qui renvoie le jeton SAML à la partie de confiance. Le corps de cette requête POST contient les revendications demandées par la partie de confiance. À ce stade, il est fréquent que la partie de confiance empaquète les revendications dans un cookie afin que l’utilisateur n’ait pas besoin d’être redirigé pour chaque demande.