Partager via

Autorisation dans les applications et services web basés sur les revendications

  • Article

Mise à jour : 19 juin 2015

S’applique à : Azure

S'applique à

  • Microsoft Azure Active Directory Access Control (également appelé Access Control Service ou ACS)

  • Windows® Identity Foundation (WIF)

  • ASP.NET

  • Windows Communication Foundation (WCF)

Résumé

Dans une application de partie de confiance, une autorisation détermine les ressources auxquelles une identité authentifié est autorisé à accéder et les opérations qu'elle est autorisée à exécuter sur ces ressources. Une autorisation incorrecte ou faible entraîne la divulgation d'informations et la falsification de données. Cette rubrique décrit les approches disponibles pour implémenter l’autorisation pour les applications et services web prenant en charge les revendications ASP.NET à l’aide d’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 version initiale, .NET Framework propose un mécanisme flexible pour implémenter une autorisation. 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 de WindowsIdentity représente un utilisateur authentifié par Active Directory et GenericIdentity représente un utilisateur 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 si WindowsIdentity est membre des groupes Active Directory. 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 les rôles s'appelle le Contrôle d'accès basé sur des rôles (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 distribuer des informations sur les rôles pour prendre en charge des mécanismes d'autorisation familiers, basés sur les rôles.

Les revendications peuvent également être utilisées pour activer des décisions d'autorisation 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 Contrôle d'accès basé sur les revendications (CBAC) ou autorisation basée sur les revendications. Ce concept est expliqué dans la section « Contrôle d'accès basé sur les revendications » de cette rubrique.

Les vérifications d’autorisation sont effectuées côté application, et non côté ACS. ACS sert de service de jeton de sécurité (STS) qui émet des jetons qui portent les revendications à l’application. Les jetons sont enrichis de revendications par des 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, consultez le Kit de développement logiciel (SDK) WIF (https://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 modifier les revendications qui viennent dans le jeton que le fournisseur d’identité émet. 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.

ACS v2 WIF Authorization

Contrôle d’accès en fonction du rôle

RBAC 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 d'utilisateurs. Si un utilisateur a un rôle requis pour exécuter une action, l'accès est autorisé ; sinon, il 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, les résultats sont une valeur booléenne. Utilisez-les dans vos instructions conditionnelles. Ils peuvent être utilisés arbitrairement n'importe où dans votre code.

  • À l'aide de la demande de sécurité PrincipalPermission.Demand(). Dans cette approche, le résultat est une exception si jamais la demande n'est pas satisfaite. Cela doit répondre à 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. Elle peut être utilisée n'importe où dans votre code.

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

  • Utilisation de l’autorisation d’URL, à l’aide de la <section d’autorisation> dans web.config. Cette approche convient lorsque vous gérez l’autorisation au niveau d’une URL. Il s'agit du niveau le plus simple parmi ceux précédemment mentionnés. L'avantage de cette méthode est que des modifications sont apportées au fichier de configuration, ce qui signifie que le code ne doit pas être compilé pour tirer parti de la modification.

Expression de rôles comme 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 qui prennent en charge les revendications, le rôle est exprimé par un rôle de revendication qui doit être disponible dans le jeton. Le type de revendication du rôle est exprimé à l'aide de l'URI suivante :

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

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

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. N'oubliez pas que dans le cas de RBAC, la seule revendication utilisée était la revendication du type de rôle. Une revendication du type de rôle a été utilisée pour vérifier si l'utilisateur appartient au rôle spécifique ou non. Pour illustrer le processus de prise de décision à propos des autorisations à l'aide de l'approche basée sur les revendications, tenez-compte des é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 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 les résultats en fonction des revendications.

  5. L'accès est accordé si la valeur des résultats est true et refusé si la valeur est false. Par exemple, la règle peut être que l’utilisateur est âgé de 21 ans ou plus, vit dans l’État de Washington et a été authentifié par Windows Live ID (compte Microsoft).

ACS sert de STS qui émet des jetons qui transportent 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, consultez Groupes de règles et Règles etGuide pratique pour implémenter une logique de transformation de jeton à 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 fourni dans le cadre de WIF. ClaimsAuthorizationManager vous permet d'intercepter des requêtes entrantes et d'implémenter toute logique de votre choix pour prendre des décisions d'autorisation basées sur les 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 modifiée. Dans ce cas, l'utilisation de ClaimsAuthorizationManager n'affecte pas l'intégrité de l'application, réduisant ainsi la probabilité d'une erreur d'application suite à la modification. Pour en savoir plus sur l’utilisation de ClaimsAuthorizationManager pour implémenter le contrôle d’accès basé sur les revendications, consultez Guide pratique pour implémenter l’autorisation de revendications dans une application prenant en compte les revendications ASP.NET à l’aide de WIF et d’ACS.

Voir aussi

Concepts

Scénarios et solutions utilisant ACS