Exporter (0) Imprimer
Développer tout

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

Publication: avril 2011

Mis à jour: mars 2015

S'applique à: Azure

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

  • Windows® Identity Foundation (WIF)

  • ASP.NET

  • Windows Communication Foundation (WCF)

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 d'ACS et WIF.

  • 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.

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 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'autorisation connus basés sur le rôle.

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 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, consultez Kit de développement logiciel (SDK) 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 modifier 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

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é.

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.

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 suivant :

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, consultez Règles et groupes de règles et Implémentation de la logique de transformation de jetons à l'aide de règles.

  • Transformation des revendications arbitraires en revendications de type de rôle à l'aide de ClaimsAuthenticationManager : 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 de ClaimsAuthenticationManager pour transformer les revendications, consultez Procédure : implémentation du contrôle d'accès en fonction du rôle dans une application ASP.NET penant en charges les revendications avec ACS.

  • Mapper les revendications arbitraires vers un type de rôle à l'aide de la section de 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.

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 (compte Microsoft).

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 plus d'informations sur le moteur de règles ACS, consultez Règles et groupes de règles et Implémentation de la logique de transformation de 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 fourni 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 de 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 plus d'informations sur l'utilisation de ClaimsAuthorizationManager pour implémenter un contrôle d'accès basé sur les revendications, consultez Procédure : Implémenter une autorisation par revendications dans une application ASP.NET prenant en charge les revendications avec WIF et ACS.

Voir aussi

Ajouts de la communauté

AJOUTER
Afficher:
© 2015 Microsoft