Analyse de la gestion de l'authentification dans .NET Core

0x00 Source du problème

Lors de la création d'un nouveau site Web .NET Core projet Sélectionnez "Utiliser un compte utilisateur personnel" pour créer un projet avec des utilisateurs et une gestion des autorisations De nombreuses pages telles que enregistrement des utilisateurs et la connexion sont prêtes à utiliser AuthorizeAttribute pour effectuer diverses tâches. . Ce type de gestion des autorisations semble très pratique. Mais je ne sais pas ce que le code généré fait pour moi. Après avoir regardé le tableau de données généré, les fonctions sont assez compliquées. En fait, tout ce dont j'ai besoin est une gestion de l'authentification basée sur les utilisateurs et les rôles, et les informations sur les utilisateurs utilisent les bibliothèques existantes. Cependant, l'utilisation du composant d'authentification fourni avec .NET Core doit s'appuyer sur EF, et de nombreuses structures de tables ne correspondent pas, donc l'apprentissage. J'ai implémenté le composant d'authentification intégré, puis écrit mon propre service d'authentification pour remplacer le composant Identity. En même temps, le Cookie était géré à l'aide du Cookie intégré middleware , vous pouvez utiliser AuthorizeAttribute pour l'authentification. Je n'ai pas encore rencontré d'exigences complexes, alors je viens d'apprendre ici. Ce blog se concentre sur l'authentification basée sur les utilisateurs et les rôles dans le cas le plus simple. Pour une utilisation de base des composants d'authentification intégrés de .NET Core, veuillez vous référer à http://www.php.cn/.

0x01 Gestion de l'authentification dans .NET Core

En matière de gestion de l'authentification, le Premier ministre pense à l'enregistrement, à la connexion, à la déconnexion et à l'ajout des utilisateurs/ Supprimez des fonctionnalités telles que les caractères . Les informations sur les utilisateurs, les informations sur les rôles, etc. sont toutes stockées dans la base de données. Il comprend donc principalement deux parties : le fonctionnement de la base de données et la logique métier de connexion. Au niveau de la logique métier de connexion, .NET Core est principalement géré via trois classes principales UserManager, RoleManager et SigninManager (dans l'assembly Microsoft.AspNetCore.Identity). Parmi eux :

UserManager est principalement responsable de l'authentification, de l'enregistrement, de la modification, de la suppression et de la gestion des rôles, jetons, déclarations liés aux utilisateurs, etc.
RoleManager est responsable de la gestion des rôles et des déclarations liées aux rôles.
SigninManager est responsable de la connexion, de la déconnexion et d'autres opérations connexes. Lorsque des opérations utilisateur sont impliquées (telles que la vérification de l'utilisateur lors de la connexion), UserManager sera appelé pour effectuer des opérations.

Lors de l'exploitation de la base de données, ces trois classes principales utilisent UserStore et RoleStore au niveau de la base de données (dans l'assembly Microsoft.AspNetCore.Identity.EntityFrameworkCore). La relation commerciale est illustrée dans la figure ci-dessous :

Nous pouvons utiliser ces trois classes principales lors du développement de fonctions liées à l'authentification . La plupart des besoins. Lorsque nous utilisons les objets de ces classes principales, ils sont obtenus via Injection de dépendances Alors, quand ces dépendances associées sont-elles injectées ? Il existe une méthode d'extension AddIdentity dans la méthode ConfigureServices de Startup, dans laquelle toutes les dépendances requises sont ajoutées.

0x02 Connexion et déconnexion

Après avoir compris la division globale du travail du composant Identité, commençons jetez un œil à la connexion et aux détails partiels de l’opération de déconnexion. SigninManager est principalement responsable du processus de connexion et de déconnexion. Jetons d'abord un coup d'œil au processus de connexion :

Réponse après. connexion réussie Header contient Set-Cookie La Clé du cookie doit être cohérente avec la clé du cookie à déchiffrer définie dans le middleware des cookies. Ceci est montré dans la capture d'écran. La clé du cookie est IdentityCookie. Définissez le cookie et renvoyez une redirection 302 vers la page de connexion.

Lorsqu'elle est redirigée vers la page de connexion, la requête contient déjà un cookie avec la clé définie sur IdentityCookie.

Le processus de déconnexion est relativement simple, appelez HttpContext.Authentication Méthode .SignOutAsync pour se déconnecter, à ce moment Set-Cookie sera ajouté à HttpContext.Response, mais le contenu sera vide.

0x03 Identifiez l'utilisateur via Cookie

Dans .NET Core via CookieAuthenticationMiddleware est un middleware qui identifie les cookies liés à l'authentification dans HttpContext, ajoutant ainsi les informations d'authentification et d'autorisation de l'utilisateur . La chose la plus critique est l'objet ClaimsPrincipal, qui enregistre les informations d'authentification et d'autorisation de l'utilisateur (en plus de cela, bien sûr, il peut également contenir d'autres toutes les informations dont vous avez besoin comme vous pouvez le voir lors du processus de connexion). ci-dessus, une fois que l'utilisateur s'est connecté avec succès, les informations d'authentification et d'autorisation sont enregistrées dans l'objet ClaimsPrincipal (en fait, les informations d'authentification dans cette paire clé-valeur de cookie sont enregistrées sous ClaimsIdentity, et un ClaimsPrincipal peut contenir plusieurs ClaimsIdentity), puis ajoutez Set -Cookie aux en-têtes de HttpContext.Response, avec la clé Le CookieName et la valeur spécifiés dans le middleware Cookie sont la chaîne cryptée de cet objet. À l'avenir, HttpContext aura ce cookie. Le middleware de cookie supprimera le cookie qui correspond à ce CookieName, le décryptera et le restaurera dans l'objet ClaimsPrincipal, et définira HttpContext.User sur cet objet. Plus tard, lorsque le middleware MVC est routage vers le contrôleur et l'action correspondants, il peut archiver HttpContext.User en fonction de l'authentification et du rôle spécifiés dans l'autorisation. attribut. Si la vérification n’est pas satisfaite, passez à la page correspondante. Par conséquent, ce qu’il faut noter, c’est que le middleware Cookie doit être placé avant le middleware MVC.

ClaimsPrincipal mérite une mention spéciale ici. Un objet ClaimsPrincipal contient un ou plusieurs objets ClaimsIdentity. Un objet ClaimsIdentity correspond généralement à une certaine paire clé-valeur dans un Cookie (compréhension personnelle). Le middleware de cookies et ClaimsIdentity sont connectés via AuthenticationScheme. Lorsque nous écrivons notre propre service d'authentification plus tard, nous rendons également le AuthenticationScheme du middleware Cookie cohérent avec le ClaimsIdentity créé. Il est donc plus précis de dire que ClaimsIdentity contient des revendications pour l'authentification et les autorisations des utilisateurs, tandis que ClaimsPrincipal peut contenir plusieurs ClaimsIdentity. Lorsqu'il y a plusieurs middlewares Cookie dans le pipeline, ils se distinguent par AuthenticationScheme.

En plus d'AuthenticationScheme, il existe deux attributs plus importants dans ClaimsIdentity, UserType et RoleType, où UserType spécifie le type d'authentification de l'utilisateur et RoleType spécifie le type de vérification du rôle . Cela signifie que si je spécifie le RoleType comme "RoleName", alors lors de l'authentification du rôle, je rechercherai toutes les valeurs de type "RoleName" dans Claims et vérifierai si elles contiennent le RoleName spécifié dans Authorize. Cependant, .NET Core est fourni avec ClaimTypes et peut être utilisé directement. Par exemple, le type de rôle est ClaimTypes.Role. Si le ClaimTypes.Role intégré est utilisé lors de l'ajout d'un rôle, il n'est pas nécessaire de spécifier explicitement le RoleType lors de la création de ClaimsIdentity. L'authentification du rôle par défaut utilise ClaimTypes.Role.

L'ajout du middleware Cookie est implémenté via la méthode d'extension app.UseIdentity dans la méthode Configure au démarrage. Cette méthode d'extension ajoute en fait une variété de méthodes d'identification des cookies. Je n'en utiliserai qu'un lors de l'écriture ultérieure de ma propre gestion de l'authentification des utilisateurs.

0x04 Écrivez votre propre gestion de l'authentification des utilisateurs

Après avoir compris le processus d'authentification des utilisateurs, nous pouvons écrire notre propre gestion de l'authentification pour remplacer le composant d'identité, qui est également divisé en opérations de base de données et logique métier d'authentification . Je ne dirai pas grand-chose sur les bases de données. Elles sont toutes écrites dans la classe IdentityRepository, qui n'a que des opérations de données très simples. Pour plus de commodité, Dapper est utilisé et la base de données est Sqlite. Le programme vérifiera la table de la base de données au démarrage, et si ce n'est pas le cas, il créera automatiquement une table vide.

Le service d'authentification est également relativement simple. Il est écrit dans la classe IdentityService, qui fournit les opérations d'enregistrement et de connexion. La déconnexion est trop simple. Écrit directement dans Action. Pour plus de commodité, aucune page de gestion des rôles n'est fournie. Si vous souhaitez tester la fonction d'authentification des rôles, vous devez ajouter manuellement un rôle à la base de données, puis ajouter un rôle à l'utilisateur dans UserRoles.

Connexion :

S'inscrire :

Déconnexion :

Juste à titre de test, il existe de nombreux problèmes logiques, tels que le stockage en texte clair de mots de passe des utilisateurs. Focus sur le processus :)

0x05 Écrit à la fin

C'est la première fois que j'entre en contact avec des applicationsWeb , de nombreux concepts me sont peu familiers. Très compréhensif. Prenons l'exemple des utilisateurs d'authentification par cookies. Auparavant, je ne savais identifier les utilisateurs que via les cookies. J'ai toujours pensé qu'après avoir reçu les cookies, je trouverais les informations d'autorisation correspondantes dans la base de données ou le cache. Cependant, après avoir lu le code du middleware Cookie intégré, j'ai réalisé que les informations d'authentification sont directement stockées dans le Cookie, il suffit donc de les déchiffrer et de les désérialiser. L'assembly Identity implique de nombreux autres assemblys (Sécurité, HttpAbstraction, etc.), ce qui m'a donné le vertige. Finalement, j'ai finalement compris, mais je n'ai pas approfondi de nombreux détails. Une partie du contenu de l'article est basée sur du code. , et certains sont basés sur une compréhension personnelle, j'espère que tout le monde sera miséricordieux s'il y a des erreurs.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!