[Transfer]asp.net Authority Authentication: Digest Authentication (Digest authentication)

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

1. asp: Forms Authentication
2. asp: HTTP Basic authentication (HTTP base)
3. NET rights authentication: Windows Authentication
4. asp: Digest Authentication (Digest authentication)
5. asp: Owin Implementation of OAuth 2.0 client-side mode (credential)
6. asp: Owin Implementation of the OAuth 2.0 password mode (Resource Owner Password credential)
7. asp: Owin Implementation of the OAuth 2.0 Authorization Code mode (Authorization code)
8. asp: Owin Implementation of the OAuth 2.0 simplified mode (implicit)

Category: Permission authentication

[Transfer]asp.net Authority Authentication: Digest Authentication (Digest authentication)