Identité basée sur les revendications et des concepts en SharePoint

Modèle d'identité basée sur les 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 pourrait être le nom d'utilisateur, un autre peut être une adresse de messagerie. L'idée est un système externe identité est configuré pour donner à votre application toutes les informations que nécessaires à propos de l'utilisateur avec chaque demande, ainsi que de chiffrement pour l'assurance que les données d'identité reçues par votre application provient d'une source approuvée.

Sous ce modèle, single sign-on est beaucoup plus facile de réaliser, et votre application n'est plus responsable des points suivants :

• Authentification des utilisateurs

• Le stockage des comptes d'utilisateurs et les mots de passe

• L'appel à des annuaires d'entreprise pour rechercher des détails d'identité utilisateur

• intégration aux systèmes d'identité à partir d'autres plateformes ou entreprises.

Sous ce modèle, votre application prend liée à l'identité des décisions basées sur des revendications fournies par l'utilisateur. Ceci peut être quelque chose à partir de la personnalisation de l'application simple avec prénom son, pour autoriser l'utilisateur pour accéder aux fonctionnalités de la valeur supérieurs et les ressources dans votre application.

Les sections suivantes présentant la terminologie et concepts pour vous aider à comprendre l'architecture d'identité basée sur les revendications.

Identité : Un ensemble d'attributs qui décrivent une entité

Identity représente un ensemble d'attributs qui décrivent un utilisateur ou une autre entité, dans un système que vous souhaitez d'informations sécurisé.

Revendication : Une information identité

Pensez à une revendication comme un élément d'information d'identité (par exemple, nom, adresse de messagerie, âge ou l'appartenance au rôle de ventes). Les revendications plus reçoit de votre application, plus vous savez sur votre nom d'utilisateur. Elles sont appelées « réclamations » au lieu de « attributs » comme couramment utilisées pour décrire les annuaires d'entreprise, en raison de la méthode de remise. Dans ce modèle, votre application ne recherche pas les attributs utilisateur dans un répertoire. Au lieu de cela, l'utilisateur fournit des revendications à votre application, et votre application examine les. Chaque déclaration est réalisée par un émetteur et vous approuvez la revendication uniquement autant que vous faites confiance l'émetteur. Par exemple, vous approuvez une revendication effectuée par contrôleur de domaine de votre société plus que vous approuvez une demande effectuée par l'utilisateur.

Jeton de sécurité : un ensemble sérialisé de revendications

L'utilisateur offre un ensemble de revendications pour votre application avec une demande. Dans un service web, ces revendications sont transmises dans l'en-tête de sécurité de l'enveloppe SOAP. Dans une application web basée sur navigateur, les revendications arrivent via un HTTP POST à partir de navigateur de l'utilisateur et peuvent ensuite être mis en cache dans un cookie si vous le souhaitez une session. Quelle que soit la façon dont ces revendications arrivent, ils doivent être sérialisés. Un jeton de sécurité est un ensemble sérialisé de revendications est signé numériquement par l'autorité de délivrance. La signature est importante : cela vous donne assurance que l'utilisateur n'a pas seulement constituent des revendications et les envoient à vous. Dans les situations de faible-sécurité où le chiffrement n'est pas nécessaire ou souhaité, vous pouvez utiliser des jetons non signées, mais ce scénario n'est pas décrites dans cet article.

Parmi les principales fonctionnalités dans Windows Identity Foundation (WIF) est la possibilité de créer et lire des jetons de sécurité. WIF et Microsoft .NET Framework gérer tous les travaux de chiffrement et présentent votre application avec un ensemble de revendications qui peut lire.

service d'émission de jeton de sécurité (STS)

Un service d'émission de jeton de sécurité (STS) est la plomberie qui génère, les signes et les jetons de sécurité de problèmes selon les protocoles interopérables présentés dans la section « Normes » de cet article. Il est beaucoup de travail ne passe en mise en œuvre de ces protocoles, mais WIF tout ce travail fait pour vous, ce qui permet une personne qui n'est pas des protocoles expert pour obtenir un service STS et en cours d'exécution avec peu d'effort.

WIF est plus facile de créer vos propres STS. Il est également vous permet de déterminer comment implémenter la logique, ou les règles, qui appliquent il (souvent appelé stratégie de sécurité).

Autorité émettrice

Il existe de nombreux types différents d'émettre des références, à partir des contrôleurs de domaine qui émet des tickets Kerberos, à des autorités de certification qui émet le certificat X.509. Le type spécifique d'autorité abordées dans cet article les problèmes les 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é. Il doit être en mesure d'émettre les revendications appropriées, étant données la cible avoir recours à tiers et l'utilisateur émettrice de la demande et peut-être être chargé pour interagir avec les magasins d'utilisateurs à rechercher des revendications et authentifier des utilisateurs.

Quelle que soit autorité émettrice vous choisissez, il joue un rôle dans votre solution d'identité. Lorsque vous prendrez authentification en dehors de votre application en s'appuyant sur les revendications, vous êtes en passant la responsabilité de cette autorité et lui demander d'authentifier les utilisateurs de votre part.

Parties de confiance

Lorsque vous générez une application qui repose sur les revendications, vous générez une application de partie de confiance. Synonymes pour une partie de confiance incluent « application prenant en charge les revendications » et « application claims-based ». Les applications Web et des services web peuvent être parties de confiance.

Une application de partie de confiance consomme des jetons émis par un service STS et extrait les revendications à partir de jetons à les utiliser pour l'identité des tâches connexes. Les service STS prend en charge deux types de confiance partie application : ASP.NET des applications web et les services web Windows Communication Foundation (WCF) .

Normes

Pour faire tout cela interopérables, plusieurs WS-* des standards dans le scénario précédent. Stratégie est récupérée à l'aide de WS-MetadataExchange, et la stratégie proprement dite est structurée conformément à la spécification de WS-Policy. Le service STS expose les systèmes d'extrémité qui implémentent la spécification de WS-Trust, qui décrivent comment obtenir les jetons de sécurité. Jeton de sécurité de la plupart des services jetons problème today mis en forme avec SAML Security Assertion Markup Language (). SAML est un vocabulaire XML reconnu qui peut être utilisé pour représenter des revendications de manière interopérable. Ou, dans une situation multiplateforme, cela vous permet de communiquer avec un service STS sur une plate-forme totalement différent et assurer, single sign-on dans l'ensemble de toutes vos applications, quelle que soit la valeur de la plateforme.

Applications basées sur le navigateur

Clients intelligents ne sont pas les seuls qui peuvent utiliser le modèle d'identité basée sur les revendications. Des applications basées sur le navigateur (également appelées clients passives) peuvent également l'utiliser. Le scénario suivant explique comment il fonctionne.

Tout d'abord, l'utilisateur pointe un navigateur à une application web prenant en charge les revendications (applications de tiers la partie de confiance). L'application web redirige le navigateur vers le service STS afin que l'utilisateur peut être authentifié. Le service STS est hébergée dans une application web simple qui lit la demande entrante, authentifie l'utilisateur à l'aide des mécanismes HTTP standards, puis crée un jeton SAML et répond à un morceau de code ECMAScript (JavaScript, JScript) qui provoque le navigateur initier une publication HTTP qui envoie le jeton SAML retour à la partie de confiance. Le corps de ce message contient les revendications qui demande la partie de confiance. À ce stade, il est courant pour la partie de confiance empaqueter les revendications dans un cookie de sorte que l'utilisateur ne dispose pas soient redirigés pour chaque demande.

Service d’émission de jetons Revendications vers Windows (c2WTS)

Le Service d'émission de jetons Revendications vers Windows (c2WTS) est une fonctionnalité de Windows Identity Foundation (WIF). Le c2WTS extrait les revendications de nom principal (UPN) utilisateur autres que Windows jetons de sécurité, tels que les jetons SAML et X.509 et génère des jetons de sécurité au niveau d'emprunt d'identité Windows. Cela permet à une application de tiers partie de confiance emprunter l'identité de l'utilisateur. Cela peut-être être nécessaires pour accéder aux ressources du serveur principal, tels que des serveurs Microsoft SQL, qui sont externes à l'ordinateur qui exécute l'application partie partie de confiance.

Le c2WTS est un service Windows qui est installé dans le cadre de WIF. Pour des raisons de sécurité, le c2WTS fonctionne uniquement sur une base d'inclusion. Il doit être démarré manuellement et il s'exécute en tant que compte système local. Un administrateur doit également configurer manuellement l' c2WTS avec une liste d'appelants autorisés. Par défaut, la liste est vide.

Si votre application de partie de confiance s'exécute en tant que compte système local, il n'a pas d'utiliser le c2WTS. Mais, si votre application de partie de confiance s'exécute en tant que le compte service réseau ou est une application ASP.NET , par exemple, il devront utiliser le c2WTS pour accéder aux ressources sur un autre ordinateur.

Supposons que vous avez une batterie de serveurs web qui se compose d'un serveur qui exécute une application ASP.NET , qui accède à une base de données SQL sur un serveur principal. Vous souhaitez rendre cette application prenant en charge les revendications. Mais, l'application ne peut pas accéder à la base de données SQL à l'aide de la revendication qu'il reçoit d'un service STS. Au lieu de cela, il utilise le c2WTS pour convertir la revendication UPN sur un jeton de sécurité Windows. Cela lui permet d'accéder à la base de données SQL.

Voir aussi

• Authentification, autorisation et sécurité dans SharePoint

• Exemple de scénario de délégation, de fédération et d’authentification dans SharePoint

• Définitions de termes d'identité basée sur les revendications