.NET Core certification management analysis

Authentication management analysis in .NET Core

0x00 Source of the problem

When creating a new .NET Core Web project Select "Use personal user account" to create a project with users and permission management. Many pages such as user registration and login are ready. You can also use AuthorizeAttribute to perform various tasks. This kind of permission management seems to be very convenient. But I'm at a loss as to what the generated code does for me. After looking at the generated data table, the functions are quite complicated. In fact, all I need is authentication management based on users and roles, and user information uses existing libraries. However, using the authentication component that comes with .NET Core must rely on EF, and many table structures do not match up, so I need to learn I implemented the built-in authentication component, and then wrote my own authenticationservicereplaced the Identity component, and Cookiemanaged using the built-in Cookiemiddleware , you can use AuthorizeAttribute for authentication. I haven’t encountered complex requirements yet, so I just learned here. This blog focuses on user- and role-based authentication in the simplest case. For some basic usage of .NET Core’s built-in authentication components, please refer to http://www.php.cn/.

0x01 Authentication management in .NET Core

When it comes to authentication management, what comes to mind is user registration, login, logout and adding/ to users Delete roles and other functions. User information, role information, etc. are all stored in the database. So it mainly includes two parts: Database operation and login business logic. At the login business logic level, .NET Core is mainly managed through three core classes UserManager, RoleManager, and SigninManager (in the Microsoft.AspNetCore.Identity assembly). Among them:

• UserManager is mainly responsible for user authentication, registration, modification, deletion, and management of user-related roles, tokens, claims, etc.

• RoleManager is responsible for the management of roles and role-related statements.

• #SigninManager is responsible for login, logout and other related operations. When user operations are involved (such as user verification during login), UserManager will be called to perform operations.

When these three core classes operate the database, they use UserStore and RoleStore at the database level (in the Microsoft.AspNetCore.Identity.EntityFrameworkCore assembly). The business relationship is shown in the figure below:

We can use these three core classes when developing authentication-related functions. Most needs. When we use the objects of these core classes, they are obtained through dependency injection. So when are these related dependencies injected? There is an AddIdentity extension method in the ConfigureServices method of Startup, in which all required dependencies are added.

##0x02 Login and logout

After understanding the overall division of labor of the Identity component, let’s take a look at login and partial details of the logout operation. The login and logout process is mainly responsible for SigninManager. Let’s take a look at the login process first:

Response after successful login Header contains Set-Cookie. The Key of the Cookie needs to be consistent with the Key of the Cookie to be decrypted set in the Cookie middleware. This is shown in the screenshot. The Key of Cookie is IdentityCookie. Set the cookie and return a 302 redirect to the login page.

When redirected to the login page, the request already contains a cookie with the key set to IdentityCookie.

The logout process is relatively simple, call HttpContext.Authentication.SignOutAsync method to log out. At this time, Set-Cookie will be added to HttpContext.Response, but the content will be empty.

0x03 Identify the user through Cookie

Pass CookieAuthenticationMiddl## in .NET Core #eware This middleware identifies authentication-related cookies in the HttpContext, thereby adding the user's authentication and authorization information. The most critical thing is the ClaimsPrincipal object, which records the user's authentication and authorization information (in addition to this, of course it can also contain otherany information you need). As you can see from the login process above, after the user successfully logs in The authentication and authorization information is saved to the ClaimsPrincipal object (actually, the authentication information in this Cookie key-value pair is saved as ClaimsIdentity, and one ClaimsPrincipal can contain multiple ClaimsIdentity), and then add Set-Cookie to the Headers of HttpContext.Response, with the Key The CookieName and Value specified in the Cookie middleware are the encrypted string of this object. In the future, HttpContext will have this cookie. The cookie middleware will take out the cookie that matches this CookieName, decrypt and restore it to the ClaimsPrincipal object, and set HttpContext.User to this object. Later MVC middleware can check in HttpContext.User based on the authentication and role specified in the Authorize attribute when routing to the corresponding Controller and Action. If the check is not satisfied, it will jump to the corresponding page. Therefore, what needs to be noted is that the Cookie middleware must be placed before the MVC middleware.

We need to talk about ClaimsPrincipal in particular. A ClaimsPrincipal object contains one or more ClaimsIdentity objects. A ClaimsIdentity object generally corresponds to a certain key-value pair in a Cookie (personal understanding). Cookie middleware and ClaimsIdentity are connected through AuthenticationScheme. When we write our own authentication service later, we also make the AuthenticationScheme of the Cookie middleware consistent with the created ClaimsIdentity. So it is more accurate to say that ClaimsIdentity contains claims for user authentication and permissions, while ClaimsPrincipal can contain multiple ClaimsIdentity. When there are multiple Cookie middlewares in the pipeline, they are distinguished by AuthenticationScheme.

In addition to AuthenticationScheme, there are two more important attributes in ClaimsIdentity, UserType and RoleType, where UserType specifies the user authentication type and RoleType specifies the role verification type. This means that if I specify the RoleType as "RoleName", then during role authentication, I will look for all values ​​of Type "RoleName" in Claims and check whether they contain the RoleName specified in Authorize. However, .NET Core comes with ClaimTypes and can be used directly. For example, the role type is ClaimTypes.Role. If you use the built-in ClaimTypes.Role when adding a role, you do not need to explicitly specify the RoleType when creating ClaimsIdentity. The default role authentication uses ClaimTypes.Role.

The addition of Cookie middleware is implemented through the app.UseIdentity extension method in the Configure method in Startup. This extension method actually adds a variety of cookie identification methods. I will only use one when writing my own user authentication management later.

0x04 Write your own user authentication management

After understanding the user authentication process, we can write our own authentication management to replace the Identity component, which is also divided into database operations and authentication business logic. I won’t say much about the database. I have written it all in the IdentityRepository class, which only has very simple data operations. For convenience, Dapper is used, and the database is Sqlite. The program will check the database table when it starts, and if it does not, it will automatically create an empty table.

The authentication service is also relatively simple. It is written in the IdentityService class, which provides registration and login operations. Logout is too simple. Written directly in Action. For convenience, no role management page is provided. If you want to test the role authentication function, you need to manually add Role to the database, and then add Role to the user in UserRoles.

log in Register:

Logout:

Just for testing, there are many logical problems, such as clear text storage of user passwords. Focus on the process:)

0x05

Written at the end

This is my first contact with Webapplication, many concepts are not Know well. Take Cookie authentication users as an example. Before, I only knew how to identify users through Cookies. I always thought that after receiving Cookies, I would find the corresponding permission information from the database or

cache

. However, after reading the built-in Cookie middleware code, I realized that the authentication information is directly stored in the Cookie, so it only needs to be decrypted and deserialized. The Identity assembly involves many other assemblies (Security, HttpAbstraction, etc.), which made me dizzy. Finally, I finally figured it out, but I didn’t delve into many details. Some of the content in the article is based on code, and some is based on personal understanding. , I hope everyone will be merciful if there are any mistakes.

The above is the detailed content of .NET Core certification management analysis. For more information, please follow other related articles on the PHP Chinese website!