Exporter (0) Imprimer
Développer tout

Autorisation dans les services et applications prenant en charge les revendications

Publication: avril 2011

Mis à jour: mai 2011

S'applique à: Windows Azure

S'applique à

  • Microsoft® Windows Azure™ AppFabric Access Control Service (ACS)

  • Windows® Identity Foundation (WIF)

  • ASP.NET

  • Windows Communication Foundation (WCF)

Résumé

Dans une application de partie de confiance, l'autorisation détermine les ressources auxquelles une identité authentifiée est autorisée à accéder ainsi que les opérations qu'elle est autorisée à réaliser sur ces dernières. Une autorisation inappropriée ou faible conduit à la divulgation d'informations et à la falsification de données. Cette rubrique décrit les méthodes disponibles pour implémenter une autorisation concernant les applications et les services Web ASP.NET prenant en charge les revendications à l'aide de ACS et WIF.

Objectifs

  • Répertorier les méthodes d'autorisation utilisées par les revendications.

  • Donner un aperçu de la conception de haut niveau pour chaque méthode.

  • Indiquer les avantages et inconvénients de chaque méthode.

Vue d'ensemble

Depuis sa première version, .NET Framework propose un mécanisme souple pour l'implémentation d'autorisations. Celui-ci est basé sur deux interfaces simples : IPrincipal et IIentité. Les implémentations concrètes de IIentité représentent un utilisateur authentifié. Par exemple, l'implémentation WindowsIdentity représente un utilisateur qui est authentifié par Active Directory et GenericIdentity représente un utilisateur qui est authentifié par une authentification personnalisée. Les implémentations concrètes de IPrincipal aident à vérifier les autorisations à l'aide de rôles en fonction du magasin de rôles. Par exemple, WindowsPrincipal vérifie l'adhésion des membres des groupes Active Directory à WindowsIdentity. Cette vérification est réalisée en appelant la méthode IsInRole dans l'interface IPrincipal. La vérification de l'accès basé sur un rôle est intitulée le Contrôle d'accès basé sur un rôle (RBAC). Ce concept est expliqué dans la section « Contrôle d'accès basé sur un rôle » de cette rubrique. Les revendications peuvent être utilisées pour apporter des informations sur un rôle afin de prendre en charge les mécanismes d'autorisations connus basés sur le rôle.

Les revendications peuvent également être utilisées pour activer des décisions d'autorisations beaucoup plus riches au-delà des rôles. Les revendications peuvent être basées sur quasiment tout : âge, code postal, pointure, etc. La vérification de l'accès basé sur les revendications arbitraires est intitulée le Contrôle d'accès basé sur les revendications (CBAC) ou autorisation basée sur les revendications. L'autorisation basée sur les revendications est expliquée dans la section « Contrôle d'accès basé sur les revendications » de cette rubrique.

Les vérifications d'autorisation sont réalisées du côté application et non pas du côté ACS. ACS sert de service d'émission de jeton de sécurité (STS) qui émet des jetons portant les revendications à l'application. Les jetons sont enrichis de revendications par les fournisseurs d'identité et éventuellement par ACS lui-même, à l'aide de son moteur de règles. Lorsque l'application reçoit le jeton avec les revendications, elle peut l'analyser, extraire les revendications pertinentes et prendre des décisions d'autorisation à l'aide soit du Contrôle d'accès basé sur un rôle soit d'une approche basée sur les revendications. WIF est utilisé pour analyser le jeton et le rendre utilisable pour les décisions d'autorisation à travers une interface de programmation d'applications (API) facile à utiliser. Pour plus d'informations sur WIF, voir Kit de développement logiciel WIF (http://go.microsoft.com/fwlink/?LinkID=187481). Envisagez le diagramme suivant lorsque vous pensez aux autorisations dans les applications et services prenant en charge les revendications. Notez qu'après une authentification réussie, le fournisseur d'identité génère un jeton (le jeton IdP sur le schéma). Le jeton IdP peut être transformé par le moteur de règles ACS. ACS peut ajouter, supprimer ou changer les revendications qui sont fournies avec le jeton émis par le fournisseur d'identité. Enfin, le jeton émis par ACS est envoyé à l'application et traité par WIF. La vérification d'accès a lieu sous WIF, à l'aide du contrôle d'accès basé sur un rôle ou du contrôle d'accès basé sur les revendications.

Autorisation WIF ACS v2

Contrôle d'accès basé sur un rôle

Le contrôle d'accès basé sur un rôle est une méthode d'autorisation dans laquelle les autorisations utilisateur sont gérées et appliquées par une application basée sur les rôles des utilisateurs. Si un utilisateur a un rôle qui est requis pour réaliser une action, l'accès est autorisé ; sinon, l'accès est refusé.

Méthode IPrincipal.IsInRole

Pour implémenter l'approche du contrôle d'accès basé sur un rôle dans les applications prenant en charge les revendications, utilisez la méthode IsInRole() de l'interface IPrincipal, comme vous le feriez dans les applications ne prenant pas en charge les revendications. Il existe plusieurs moyens d'utiliser la méthode IsInRole() :

  • En faisant explicitement appel à IPrincipal.IsInRole(« Administrateur »). Dans cette approche, le résultat est un booléen. Utilisez-le dans vos instructions conditionnelles. Il peut être utilisé de manière arbitraire à n'importe quel emplacement dans votre code.

  • À l'aide de la demande de sécurité PrincipalPermission.Demand(). Dans cette approche, le résultat est une exception au cas où la demande ne serait pas satisfaite. Ceci doit correspondre à votre stratégie de gestion des exceptions. La levée des exceptions s'avère beaucoup plus coûteuse du point de vue de la performance par rapport à la suppression du booléen. Ceci peut être utilisé à n'importe quel emplacement de votre code.

  • À l'aide des attributs déclaratifs [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)]. Cette approche est appelée déclarative, car elle sert à décorer les méthodes. Elle ne peut pas être utilisée dans les blocs de code au sein des implémentations de la méthode. Le résultat est une exception au cas où la demande ne serait pas satisfaite. Vous devez vous assurer qu'elle correspond à votre stratégie de gestion des exceptions.

  • À l'aide de l'autorisation d'URL, à l'aide de la section <autorisation> dans web.config. Cette approche convient lorsque vous gérez l'autorisation au niveau de l'URL. C'est le niveau le plus grossier parmi ceux mentionnés précédemment. L'avantage de cette approche est que les modifications sont effectuées dans le fichier de configuration, ce qui implique que le code ne doit pas être compilé pour profiter du changement.

Expression des rôles en revendications

Lorsque la méthode IsInRole() est appelée, une vérification est effectuée pour voir si l'utilisateur actuel dispose de ce rôle. Dans les applications prenant en charge les revendications, le rôle est exprimé par un type de revendication du rôle qui doit être disponible dans le jeton. Le type de revendication du rôle est exprimé à l'aide de l'URI suivante :

http://schemas.microsoft.com/ws/2008/06/identity/claims/role

Il existe plusieurs moyens d'enrichir un jeton avec un type de revendication du rôle :

  • À l'aide du moteur de règles ACS —Dans ce cas, vous créez une règle à l'aide du portail de gestion ACS ou du service de gestion ACS pour créer des règles de transformation des revendications qui génèrent des revendications d'un certain type de rôle. Pour plus d'informations sur les règles et la transformation des jetons, voir Groupes de règles et règles ainsi que Implémentation de la logique de transformation des jetons à l'aide de règles.

  • Transformation des revendications arbitraires en revendications de type de rôle à l'aide du ClaimsAuthenticationManager  : le ClaimsAuthenticationManager est un composant fourni dans le cadre de WIF. Il permet d'intercepter les requêtes lorsqu'elles lancent une application, en inspectant les jetons et en les transformant par l'ajout, le changement ou la suppression de revendications. Pour plus d'informations sur l'utilisation du ClaimsAuthenticationManager pour transformer les revendications, voir implémentation du contrôle d'accès basé sur les rôles (RBAC) dans une application ASP.NET prenant en charge les revendications à l'aide de WIF et ACS

  • Mapper les revendications arbitraires vers un type de rôle à l'aide de la section configuration du samlSecurityTokenRequirement : une approche déclarative où la transformation des revendications est réalisée uniquement à l'aide de la configuration et où aucun codage n'est requis.

Contrôle d'accès basé sur les revendications

Le contrôle d'accès basé sur les revendications est une approche d'autorisation où la décision d'autorisation d'accorder ou de refuser l'accès est basée sur une logique arbitraire qui utilise les données disponibles dans les revendications pour prendre la décision. Rappelons que dans le cas du contrôle d'accès basé sur un rôle, la seule revendication utilisée était la revendication de type de rôle. Une revendication de type de rôle était utilisée pour vérifier si l'utilisateur appartenait ou non à un rôle spécifique. Pour illustrer le processus de prise de décisions d'autorisation à l'aide d'une approche d'autorisation basée sur les revendications, envisagez les étapes suivantes :

  1. L'application reçoit une requête.

  2. L'application extrait les revendications entrantes.

  3. L'application transmet les revendications au mécanisme de la logique de décision. Ce peut être un code en mémoire ou un appel à un service Web, une requête envoyée à une base de données ou un appel vers un moteur de règles sophistiqué.

  4. Le mécanisme de décision calcule le résultat en fonction des revendications.

  5. L'accès est accordé si le résultat est « true » et il est refusé s'il est « false ». Par exemple, la règle peut être que l'utilisateur soit au moins âgé de 21 ans, vive dans l'État de Washington et soit authentifié par Windows Live® ID.

ACS sert de STS qui émet les jetons portant les revendications. Vous pouvez contrôler les revendications émises - les types de revendications et les valeurs - à l'aide du moteur de règles ACS. Pour en savoir plus sur le moteur de règles ACS, voir Groupes de règles et règles ainsi que Implémentation de la logique de transformation des jetons à l'aide de règles. ClaimsAuthorizationManager est essentiel pour implémenter le contrôle d'accès basé sur les revendications dans les applications prenant en charge les revendications. ClaimsAuthorizationManager est un composant livré dans le cadre de WIF. ClaimsAuthorizationManager vous permet d'intercepter les requêtes entrantes et d'implémenter la logique de votre choix pour prendre les décisions d'autorisation en fonction des revendications entrantes. C'est également un point d'extensibilité où les décisions d'autorisation peuvent être externalisées et découplées à partir du code de l'application. Cela devient important lorsque la logique d'autorisation doit être changée. Dans ce cas, l'utilisation du ClaimsAuthorizationManager n'affectera pas l'intégrité de l'application, réduisant ainsi la probabilité qu'une erreur d'application résulte du changement. Pour en savoir plus sur la façon d'utiliser ClaimsAuthorizationManager pour implémenter un contrôle d'accès basé sur les revendications, voir Implémentation de l'autorisation de revendications dans une application ASP.NET prenant en charge les revendications à l'aide de WIF et d'ACS.

Éléments liés

Voir aussi

Afficher:
© 2014 Microsoft