There are three types of authentication, namely "Windows | Forms | Passport", among which Forms verification is the most used and the most flexible.
The Forms verification method provides good support for user-based authentication authorization. You can verify the identity of the user through a login page and send the identity of this user back to the client's cookie. After that, the user will access the web application and send it to the server together with the identity cookie. The authorization settings on the server can control the access authorization of different users according to different directories.
The problem is that in actual use, what we often need is role-based or user group-based authentication and authorization. For a website, the general verification and authorization model should be as follows: the user is divided into different identities according to actual needs, that is, roles, or user groups. The verification process not only needs to verify the identity of the user, but also needs to verify which role it belongs to. Access authorization is set according to roles, which resources can certain roles access, which resources cannot be accessed, etc. It would be very impractical to authorize access based on users. There are many users, and they may increase or decrease at any time. It is impossible to increase access authorization for the increasing number of new users in the configuration file at any time.
Let’s take a look at the Forms process.
The basic principles of Forms authentication:
1 Authentication
To use Forms authentication, you must first make corresponding settings in the application root directory:
<authentication mode="forms">
<forms name=".ASPXAUTH" loginUrl="/" timeout="30" path= "/">
</forms>
</authentication>
Where <authentication mode= "forms"> means that this application uses Forms verification.
1. The name in the <forms> tag indicates the HTTP cookie to use for authentication. By default, the value of name is .ASPXAUTH. After verifying the user in this way, a FormsAuthenticationTicket type authentication ticket is created using the user's information, and then encrypted and serialized into a string. Finally, the string is written to the cookie with the name specified by the client. Once the cookie is written to the client, the user will send it 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 what information does the authentication ticket contain, let’s take a look at the FormsAuthenticationTicket class:
CookiePath: Returns the path to issue the cookie. Note that the path of the form is set to /. Because forms are case sensitive, this is a protection measure taken to prevent inconsistent case of URLs in the site. This is used when refreshing cookies
Expiration: Get the date/time when the cookie expires.
IsPersistent: Returns true if a persistent cookie has been issued. Otherwise, authentication cookies will be limited to the browser lifecycle.
IssueDate: Gets the date/time when the cookie was originally issued.
Name: Gets the username associated with the authentication cookie.
UserData: Gets the application definition string stored in the cookie.
Version: Returns the byte version number for future use.
2. The loginUrl in the <forms> tag specifies the URL to which the request will be redirected for the login if no valid authentication cookies are found. The default value is . The page specified by loginUrl is used to verify the identity of the user. Generally, this page provides the user input user name and password. After the user submits, the program will verify the legitimacy of the user according to its own needs (mostly, the user input information is compared with the user table in the database). If the verification user is valid, an identity verification ticket corresponding to this user is generated, a cookie is written to the client, and finally the browser is redirected to the page requested by the user in the initial trial. Generally, a series of actions such as generating an identity verification ticket, writing back to the client, and browser redirection are completed.
public static void RedirectFromLoginPage( string userName, bool createPersistentCookie, string strCookiePath );
in:
userName: It is the label of this user, which is used to mark the unique label of this user and does not necessarily need to be mapped to the user account name.
createPersistentCookie: Indicates whether to issue persistent cookies.
If it is not a persistent cookie, the Expiration attribute of the cookie has the current time plus the time out. Each time you request the page, during the verification process, it will determine whether half of the validity period has passed. If so, the validity period of the cookie is updated once. If it is a persistent cookie, the Expiration attribute is meaningless. At this time, the validity period of the identity verification ticket is determined by the cookie. The RedirectFromLoginPage method sets the Expires attribute to a 50-year validity period for the Expires attribute.
strCookiePath: indicates the path to write the generated cookie to the client. The path saved in the authentication ticket is used when refreshing the authentication ticket cookie (this is also the path that generates the cookie). If there is no strCookiePath parameter, the path attribute is set in use.
As you can see here, there are only three parameters of this method, and there are seven attributes of the authentication ticket. This is how the insufficient four parameters come from:
IssueDate: The cookie issuance time is derived from the current time,
Expiration: The expiration time is calculated from the current time and the timeout parameter in the <forms> tag to be mentioned below. This parameter is meaningful for non-persistent cookies.
UserData: This property can be written into some user-defined data using the application. This method does not use this property. It simply sets this property to an empty string. Please note this property. We will use this property later.
Version: The version number is automatically provided by the system.
After the RedirectFromLoginPage method generates the authentication ticket, it will call the method to encrypt the authentication ticket as a string. This string will be the value of a cookie with the name .ASPXAUTH. The generation of other attributes of this cookie: Domain, the Path attribute is a valid value, Expires depends on the createPersistentCookie parameter. If it is a persistent cookie, Expires will be set to expire after 50 years; if it is a non-persistent cookie, the Expires attribute will not be set.
After generating an authentication cookie, add this cookie to it and wait for it to be sent to the client.
Finally, the RedirectFromLoginPage method calls the method gets the page originally requested by the user and redirects to this page.
3. The timeout and path in the <forms> tag provide the expiration time and default path for authentication tickets written to the cookie.
The above is the process based on Forms authentication, which completes the confirmation of user identity. The following describes access authorization based on Forms authentication.
2. Access Authorization
Verifying the identity is to use this identity. We can perform different operations and processing according to different identities. The most common one is to authorize different identities. Forms verification provides such a function. Forms authorization is based on a directory, and access permissions can be set for a certain directory. For example, these users can access this directory, and those users cannot access this directory.
Similarly, the authorization settings are set in the file in 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>
The <allow> tag indicates that the properties in which access is allowed
1. users: A comma-separated list of usernames that have been granted access to the resource. Question mark (?) Allow anonymous users; asterisk (*) Allows 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 transport methods that have been granted access to the resource. The predicates registered to be GET, HEAD, POST, and DEBUG.
The <deny> tag indicates that access is not allowed. The properties in it are the same as those above.
At runtime, the authorization module iterates through the <allow> and <deny> tags until it finds the first access rule suitable for a particular user. It then allows or denies access to the URL resource based on whether the first access rule found is the <allow> or <deny> rule. The default authentication rule in the file is <allow users="*"/>, so access is allowed by default unless otherwise configured.
So how do you get these users and roles? Let’s take a look at the detailed process of authorization:
1. Once a user visits this website, he can log in and confirm his identity, and the cookie of the identity verification ticket is also written to the client. After that, 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, each http request is assigned an HttpApplication object to handle this request. After the event, the security module has established a user identity, that is, the identity of this user has been established on the web side. This identity is completely established by the cookie of the identity verification ticket sent back by the client.
2. The user identity is in the attribute, and the HttpContext object related to this page can be obtained through . For Forms verification, the property is an object of type GenericPrincipal. GenericPrincipal has only one public property Identity, and has a private m_role attribute, which is a string[] type, which stores an array of roles this user belongs to. There is also a public method IsInRole(string role) to determine whether this user belongs to a certain role.
Since the cookie of the authentication ticket does not provide role at all, that is, the Forms authentication ticket does not provide role information for this user, for Forms authentication, the m_role attribute of the GenericPrincipal user object obtained on the server is always empty.
3. GenericPrincipal. Identity attribute is an object of FormsIdentity type. This object has a Name attribute, which is the user's label. Access authorization is to use this attribute as a user for authorization verification. There is another attribute in FormsIdentity, which is the Ticket property. This attribute is the authentication ticket FormsAuthenticationTicket type, which is the authentication ticket written by the server to the client before.
After the server obtains the authentication ticket FormsAuthenticationTicket object, checks whether the authentication ticket is non-persistent authentication. If it is, update the cookie of the authentication ticket based on the validity period set in the timeout attribute (to avoid jeopardizing performance, update the cookie after more than half of the specified time has passed. This may result in a loss of accuracy. Persistent cookies do not time out.)
4. Before the event, start to obtain the page requested by the user and establish the HttpHandler control point. This means that when the event requires user access permissions, it is meaningless to check whether the user or role has permission to access this page. Then, it will be meaningless to change the identity or role of this user during the life cycle of this request.
The above is the entire process of Forms verification. It can be seen that this Forms verification is based on the user and does not provide direct support for role verification. The Name property in the FormsAuthenticationTicket is a user's label. In fact, there is also a property UserData. This property can be written into some custom data by the application. We can use this field to store role information to achieve the purpose of role verification.
Previous page123Next pageRead the full text