This article transferred from: http://www.cnblogs.com/lanxiaoke/p/6357501.html
Summary Certification Simple introduction
Abstract authentication is the improvement of the basic authentication, that is, the use of abstract instead of account password, so as to prevent the disclosure of account password in plaintext transmission
Prior to the summary certification is not very familiar with, but also thanks to the Circle of Parry Contribution Blog: ASP. NETWeb API (iii): Use Digest authentication for security Validation (Digest authentication)
I feel really good, let me go a lot less detours. This article is mainly on the above cited article explanation, the old driver can skip.
The usual, the work flow chart of the certification
Look at the figure may know the summary certification steps
Client Request Resource Api/employees
Background authentication logic, return 401
After the data is submitted, the server checks the authorization information in the headers, the null value returns 401, the authentication is required, the authentication format is digest, and the values of realm, Nonce, Qop are returned.
1, the value of realm can be arbitrary; a nonce is a random number, usually a GUID-formatted string that needs to be returned in the background; there are three types of qop: no definition (i.e. null value), auth, Auth-int
2, the background processing process:
3. The message header information returned is this:
http/1.1 401 Unauthorized
Www-authenticate:digest
Realm= "Realmofbadri"
qop= "Auth"
Nonce= "75d1c31e6d3b28f100edac595a53cf96"
Client Licensing started
After receiving feedback, know that the resource needs authorization to access; and start typing username, password
Here's a place to be aware that the project by default is the account name password consistent to verify through, see the code
Click Sign in to view data from the background
Look at the picture to know
Realm, Qop, Nonce is the last value generated by the server
Username is the page we entered
URI is the address the client wants to request
NC, Cnonce is the client auto-generated value
Response is the final summary message to be delivered and is the client-generated
Did you find something wrong? Where's the code?
In fact, this is the essence of Digest authentication, do not send plaintext password, only send summary information
Some students may want to ask, do not transfer the password, the server how to know that the input user name is the current operating user?
Then we'll have to get a summary of the information, let's see how to generate summary information
A hash operation is performed on (Username:realm:password) to get HA1
Hash operation (method name: request path), i.e. (get:http://localhost:32934/api/employees), get HA2
Finally get summary information response = pair (HA1:nonce:nc:cnonce:qop:HA2) for hash operation
Background parameter resolution
After analyzing the front end, we look at how the server resolves these parameters
In fact, the work of the server is based on the client side of the realm, Qop, nonce, username, Uri, NC, Cnonce Hash run to get new summary information RESPONSE2
How to compare the Response2 with the client generated response, if consistent, the certification passed; inconsistent, continue to return 401
The main thing is this section of code processing
Because for the server side HA1:nonce:nc:cnonce:qop:HA2 in addition to HA1 in the password not get from the client, all the other parameters have been
So the core of summary certification is:
For clients: I know the user name and password and (some authentication constraints, realm, Qop, nonce, etc.) to get encrypted information response
For the server: I know the user name and (some authentication constraints, that is realm, qop, nonce, etc.), and then according to the user name to the database to find the user's password, thereby obtaining the encrypted information RESPONSE2
Finally compare Response:response2, if the client entered the password and database according to the user name found the same password, it will certainly be able to pass the certification.
Finally need to remind everyone of the place, this user password can be inconsistent with the account login password, can be divided into 2 fields; You can understand: Username + authentication Password
Because the authentication password even if the encryption must be reversible, or the background can not match
Summary Certification Test
Web-side Digest authentication is the same as above.
But in many cases the client is not a resource accessed through a browser, such as a program to access Api/employees,
This time there is no interactive action like the Browser popup authentication window, how to do?
In fact, it is very simple, we create a new console project Digesttest
Then access the resource file through the WebClient object.
Last Run the program, you can see the returned data
Prompt without authorization, because our authentication account is wrong, change to 1111:1111, try again
OK, no problem at all.
All right, get it done!
ASP. NET Permission Authentication series
- asp: Forms Authentication
- asp: HTTP Basic authentication (HTTP base)
- NET rights authentication: Windows Authentication
- asp: Digest Authentication (Digest authentication)
- asp: Owin Implementation of OAuth 2.0 client-side mode (credential)
- asp: Owin Implementation of the OAuth 2.0 password mode (Resource Owner Password credential)
- asp: Owin Implementation of the OAuth 2.0 Authorization Code mode (Authorization code)
- asp: Owin Implementation of the OAuth 2.0 simplified mode (implicit)
Category: Permission authentication
[Transfer]asp.net Authority Authentication: Digest Authentication (Digest authentication)