Autorisation support de base

Les API minimales prennent en charge toutes les options d’authentification et d’autorisation disponibles dans ASP.NET Core et fournissent des fonctionnalités supplémentaires pour améliorer l’expérience de travail avec l’authentification.

Concepts clés de l’authentification et de l’autorisation

L’authentification est le processus qui consiste à déterminer l’identité d’un utilisateur. L’autorisation est le processus qui consiste à déterminer si un utilisateur a accès à une ressource. Les scénarios d’authentification et d’autorisation partagent une implémentation similaire sémantique dans ASP.NET Core. L’authentification est gérée par le service d’authentification, IAuthenticationService, qui est utilisé par le middleware d’authentification. L’autorisation est gérée par le service d’autorisation, IAuthorizationService, qui est utilisé par le middleware d’autorisation.

Le service d’authentification utilise des gestionnaires d’authentification inscrits pour effectuer des actions liées à l’authentification. Par exemple, une action liée à l’authentification consiste à authentifier un utilisateur ou à le déconnecter. Les schémas d’authentification sont des noms utilisés pour identifier de manière unique un gestionnaire d’authentification et ses options de configuration. Les gestionnaires d’authentification sont chargés d’implémenter les stratégies d’authentification et de générer les revendications d’un utilisateur en fonction d’une stratégie d’authentification particulière, telle que OAuth ou OIDC. Les options de configuration sont également propres à la stratégie et fournissent au gestionnaire une configuration qui affecte l’authentification comportement, tels que les URI de redirection.

Il existe deux stratégies pour déterminer l’accès des utilisateurs aux ressources dans la couche d’autorisation : Les

• stratégies basées sur les rôles déterminent l’accès d’un utilisateur en fonction du rôle qui lui est attribué, par exemple ou . Pour plus d’informations sur l’autorisation basée sur les rôles, consultez la documentation sur l’autorisation basée sur les rôles.
• Les stratégies basées sur les revendications déterminent l’accès d’un utilisateur en fonction des revendications émises par une autorité centrale. Pour plus d’informations sur l’autorisation basée sur les revendications, consultez la documentation sur l’autorisation basée sur les revendications.

Dans ASP.NET Core, les deux stratégies sont regroupées dans une exigence d’autorisation. Le service d’autorisation s’appuie sur les gestionnaires d’autorisations pour déterminer si un utilisateur particulier répond ou non aux exigences d’autorisation appliquées à une ressource.

Activation de l’authentification dans les applications minimales

Pour activer l’authentification, pour enregistrer les services d’authentification requis auprès du fournisseur de services de l’application.

En règle générale, une stratégie d’authentification spécifique est utilisée. Dans l’exemple suivant, l’application est configurée avec la prise en charge de l’authentification basée sur le support JWT. Cet exemple utilise les API disponibles dans le package NuGet.

Par défaut, le enregistre automatiquement les intergiciels d’authentification et d’autorisation si certains services d’authentification et d’autorisation sont activés. Dans l’exemple suivant, il n’est pas nécessaire d’appeler ou d’enregistrer les intergiciels, car cela se fait automatiquement après ou sont appelés.

Dans certains cas, comme le contrôle de l’ordre des middlewares, il est nécessaire d’enregistrer explicitement l’authentification et l’autorisation. Dans l’exemple suivant, le middleware d’authentification s’exécute après l’exécution du middleware CORS. Pour plus d’informations sur les middlewares et ce comportement automatique, consultez Middleware dans les applications API minimales.

Configuration de la stratégie d’authentification

Les stratégies d’authentification prennent généralement en charge diverses configurations qui sont chargées via des options. Les applications minimales prennent en charge les options de chargement à partir de la configuration pour les stratégies d’authentification suivantes : L’infrastructure

ASP.NET Core s’attend à trouver ces options dans la section de la configuration. Dans l’exemple suivant, deux schémas différents, et , sont définis avec leurs options respectives. Cette option permet de configurer la stratégie d’authentification par défaut utilisée.

Dans , deux stratégies d’authentification basées sur le support JWT sont enregistrées, avec le

• nom de schéma : « Bearer ».
• Nom du schéma « LocalAuthIssuer ».

« Bearer » est le schéma par défaut typique dans les applications activées basées sur le support JWT, mais le schéma par défaut peut être remplacé en définissant la propriété comme dans l’exemple précédent.

Le nom du schéma est utilisé pour identifier de manière unique une stratégie d’authentification et est utilisé comme clé de recherche lors de la résolution des options d’authentification à partir de config, comme illustré dans l’exemple suivant :

Configuration des stratégies d’autorisation dans les applications minimales

L’authentification est utilisée pour identifier et valider l’identité des utilisateurs par rapport à une API. L’autorisation est utilisée pour valider et vérifier l’accès aux ressources dans une API et est facilitée par la méthode d’inscription par extension. Dans le scénario suivant, une ressource est ajoutée qui nécessite qu’un utilisateur présente une revendication de rôle avec une revendication d’étendue.

La configuration des exigences d’autorisation sur une ressource est un processus en deux étapes qui nécessite :

1. La configuration des exigences d’autorisation dans une stratégie globale.
2. Application de stratégies individuelles aux ressources.

Dans le code suivant, AddAuthorizationBuilder est appelé qui :

• Ajoute des services liés à l’autorisation au conteneur DI.
• Renvoie un AuthorizationBuilder qui peut être utilisé pour enregistrer directement les stratégies d’autorisation.

Le code crée une nouvelle stratégie d’autorisation, nommée , qui encapsule deux exigences d’autorisation :

• une exigence basée sur un rôle via RequireRole pour les utilisateurs disposant d’un rôle.
• Une exigence basée sur une revendication via RequireClaim selon laquelle l’utilisateur doit fournir une revendication d’étendue.

La stratégie est fournie en tant que stratégie obligatoire au point de terminaison.

Tout

au long de cet article, une application configurée avec l’authentification basée sur le porteur JWT est utilisée. L’authentification basée sur le porteur JWT exige que les clients présentent un jeton dans l’en-tête de la demande pour valider leur identité et leurs revendications. En règle générale, ces jetons sont émis par une autorité centrale, telle qu’un serveur d’identité.

Lors du développement sur la machine locale, l’outil peut être utilisé pour créer des jetons de porteur.

Les jetons peuvent être configurés avec une variété de personnalisations. Par exemple, pour créer un jeton pour le rôle et l’étendue attendus par la politique d’autorisation dans le code précédent :

Le jeton généré peut ensuite être envoyé dans le cadre de l’en-tête dans l’outil de test de votre choix. Par exemple, avec curl :

Pour plus d’informations sur l’outil, consultez la documentation complète.