Basic Principles of Forms authentication

1. Authentication

To use forms authentication, you must first make the corresponding settings in Web. config in the application root directory:

<Authentication mode = "forms">
<Forms name = ". aspxauth" loginurl = "/login. aspx" timeout = "30" Path = "/">
</Forms>
</Authentication>

<Authentication mode = "forms"> indicates that the application adopts Forms authentication.
1. Name in the <forms> label indicates the HTTP cookie to be used for identity authentication. By default, the value of name is. aspxauth. After the user is verified in this way, a formsauthenticationticket authentication ticket is created based on the user information, and then encrypted and serialized into a string, finally, write the string to the cookie with the name specified by the client name. once the cookie is written to the client, the user will be sent to the server together with the cookie when accessing the web application again, and the server will know that the user has been verified.

Let's take a look at the information contained in the identity authentication ticket. Let's take a look at the formsauthenticationticket class:
Cookiepath: Return the cookie sending path. Note: the path of the form is set /. The form is case-sensitive, which is a protection measure to prevent the URL in the site from being case-insensitive. This is used when refreshing cookies.
Expiration: Get the cookie expiration date/time.
IspersistenT: If a persistent Cookie has been sent, true is returned. Otherwise, the authentication cookie is restricted within the browser lifecycle.
Issuedate: Get the date/time when the cookie was originally sent.
Name: Obtain the username associated with the authentication cookie.
Userdata: Get the application definition string stored in the cookie.
Version: Returns the byte version number for future use.

2. The loginurl in the <forms> label specifies that if no valid authentication cookie is found, it is the URL to which the login redirects the request. The default value is default. aspx. The page specified by loginurl is used to verify the user's identity. Generally, this page provides the user's user name and password, after the user submits the request, the program verifies the validity of the user based on his/her own needs (in most cases, the user input information is compared with the user table in the database). If the user is verified to be valid, generate the authentication ticket corresponding to this user, write it to the cookie of the client, and redirect the browser to the page of the user's initial request. generally, formsauthentication is used. the redirectfromloginpage method is used to generate an authentication ticket, write it back to the client, and redirect the browser.

Public static void redirectfromloginpage (string username, bool createpersistentcookie, string strcookiepath );

Where:
Username: Indicates the user's ID. It indicates the unique ID of the user. It is not necessarily mapped to the user account name.
Createpersistentcookie: Indicates whether a persistent cookie is sent.
If it is not a persistent cookie, the expiration attribute of the cookie's validity period includes the current time plus the web. the timeout time in config. When each request is sent to the page, the system checks whether half of the validity period has been passed during identity authentication. If so, the cookie validity period is updated. If it is a persistent cookie, the expiration attribute is meaningless. The validity period of the authentication ticket is determined by the cookie expires. The redirectfromloginpage method sets the validity period of the expires attribute to 50 years.
Strcookiepath: Indicates the path to write the generated cookie to the client. The path saved in the authentication ticket is used when the cookie is refreshed (this is also the path for generating the cookie ), if the strcookiepath parameter is not specified, the web. set the path attribute in config.

We can see that there are only three parameters in this method, and there are seven attributes of the identity authentication ticket. The following are the four parameters:
Issuedate: The cookie sending time is determined by the current time,
Expiration: The expiration time is calculated by the current time and the timeout parameter in the <forms> label to be mentioned below. This parameter is valid for non-persistent cookies.
Userdata:This attribute can be used to write some user-defined data. This attribute is not used in this method, but it is simply set to a null string. Please note that this attribute, this attribute will be used later.
Version:The version number is automatically provided by the system.

After the redirectfromloginpage method generates an authentication ticket, it will call the formsauthentication. Encrypt method to encrypt the authentication ticket as a string, which will be a cookie value named by. aspxauth. Other attributes of this cookie are generated: domain. The path attribute is a saved value. expires depends on the createpersistentcookie parameter. If it is a persistent cookie, expires after 50 years; if the cookie is not persistent, The expires attribute is not set.
After an authentication cookie is generated, add the cookie to response. Cookies and wait for the cookie to be sent to the client.
Finally, the redirectfromloginpage method calls the formsauthentication. getredirecturl method to obtain the page requested by the user and redirect it to this page.

3. the timeout and path in the <forms> label provide the authentication ticket write to the cookie expiration time and default path.

The above process is based on Forms authentication, which completes the confirmation of user identity. The following describes Access authorization based on Forms authentication.

2. Access Authorization

If you verify your identity, you must use this identity. You can perform different operations and processes based on different identities. The most common thing is to authorize different identities, forms authentication provides such a function. Forms authorization is based on directories. You can set access permissions for a directory. For example, these users can access this directory, and those users cannot access this directory.
Similarly, the authorization settings are set in the web. config file under the directory you want to control:
<Authorization>
<Allow users = "comma-separated list of users"
Roles = "comma-separated list of roles"
Verbs = "comma-separated list of verbs"/>
<Deny users = "comma-separated list of users"
Roles = "comma-separated list of roles"
Verbs = "comma-separated list of verbs"/>
</Authorization>

<Allow> the label indicates that access is allowed, and Its Attributes
1. Users: A comma-separated list of user names that have been granted access to resources. Question mark (?) Anonymous Users are allowed. asterisks (*) Allow all users.
2. Roles: A comma-separated list of roles that have been granted access to resources.
3. verbs: A comma-separated list of HTTP transfer methods that have been granted access to resources. The predicates registered with ASP. NET are get, Head, post, and debug.

<Deny> the tag indicates that access is not allowed. The attributes are the same as above.

At runtime, the authorization module iterates through <allow> and <deny> until it finds the first access rule suitable for a specific user. Then, it allows or denies access to URL resources based on the first access rule found: <allow> or <deny>. The default authentication rule in the machine. config file is <allow users = "*"/>. Therefore, access is allowed by default unless otherwise configured.

So how can these users and roles be obtained? The detailed authorization process is as follows:

1. Once a user accesses this website, he or she can log on and confirm his or her identity. The cookie of the authentication ticket is also written to the client. Then, the user applies for the web page again, and the cookie of the authentication ticket will be sent to the server. On the server side, Asp.net assigns an httpapplication object for each HTTP request to process the request. after the authenticaterequest event, the security module has established a user identity, that is, the identity of this user has been established on the Web end, and this identity is completely created by the cookie of the authentication ticket sent by the client. Therefore, even if resources are recycled from the server, identity recognition is not affected.
2. the user identity is in the httpcontext. User attribute. On the page, you can use page. Context to obtain the httpcontext object related to the page. For forms verification, httpcontext. the user attribute is a genericprincipal type object. genericprincipal has only one public attribute identity, which has a private m_role attribute, which is of the string [] type and stores the array of role to which the user belongs, there is also a public method isinrole (string role) to determine whether the user belongs to a role.
Note: Because the role attribute is not provided in the cookie of the authentication ticket, that is, the forms authentication ticket does not provide the role information of this user, for Forms authentication, the m_role attribute of the genericprincipal user object obtained on the server is always empty. Therefore, to control permissions based on the role, you need to add additional code, you can save the role information to the attributes of userdata and save it in the cookie together with the user information, extract related role information from the cookie and assign values each time the page is loaded.
3. The genericprincipal. Identity attribute is a formsidentity type object. This object has a name attribute, which indicates the user. Access Authorization uses this attribute as the user for authorization verification. Formsidentity also has a ticket attribute, which is the formsauthenticationticket type of authentication ticket, that is, the authentication ticket that the server previously wrote to the client.
After obtaining the authentication ticket formsauthenticationticket object, the server checks whether the authentication ticket is non-persistent authentication. the timeout attribute set in config is valid to update the cookie of the authentication ticket (to avoid compromising performance, the cookie is updated after more than half of the specified time. This may cause a loss of accuracy. Persistent cookie does not time out .)
4. Before the httpapplication. resolverequestcache event, Asp.net starts to obtain the user request page and establish the httphandler control point. This means that in httpapplication. the resolverequestcache event verifies the user's access permissions to check whether the user or role has the permission to access this page, it makes no sense to change the identity or role of the user within the lifecycle of the request.

# C # column