HTTP: no authentication _ basic authentication and digest Authentication

No authentication method

After a correct client request is sent to the server, the HTTP server returns the 200 status code and directly returns the content.

Message example:

Request:

Get. http: // 10.127.194.3: 8061/voiceobjects .....

Return Value:

HTTP/1.1.200. OK .date:. Fri,. 28. oct.20 .....

 

Ii. Basic Authentication Method

The Basic Authentication and digest authentication methods are based on a challenge-Response Authentication Mode (challenge-response authentication mechanism. Here we will first explain this Authentication mode, which is a request-response sequence:

Client A sends a "no authentication" request to the server

Server B returns 401 (unauthorized) to the client, and attaches the authentication method (basic authentication or digest authentication), realm (explained below), and other information required by the server to the client.

The C client re-organizes the request message based on the information returned by the server, and sends the request again with the authentication information.

 

The Basic Authentication and digest authentication are based on the above model, but in actual application, they do not necessarily follow the above sequence. For example, if the two parties have agreed to use some authentication method, the steps A and B can be omitted in one step.

 

Realm: this will be included in the basic authentication and digest authentication. This is the authentication classification mark specified by the server (I do not know how to better express it in Chinese: these realms allow the protected resources on a server to bepartitioned into a set of protection spaces, each with its own authenticationscheme and/or authorization database .), that is to say, when the client accesses different links, it may receive different realm flags, so as to receive different realm values, use different usernames, passwords, and other authentication information to organize the next request.

 

Basic authentication requirements:

When the server requires basic authentication, it must include the "www-authenticate" header field in the returned 401 message, followed by a "Basic" keyword, A realm and realm values are followed, separated by spaces in the middle:

Challenge = "Basic" Realm

Realm = "Realm" "=" realm-Value

Realm-value = quoted-string

When receiving a message, the client needs to carry the "Authorization" header domain, followed by a "Basic" keyword, followed by a base64 encrypted string of the user name and password connected with:

Credentials = "Basic" Basic-Credentials

Basic-Credentials = base64-user-pass

Base64-user-pass = <base64 [4] encoding of user-pass, counter t not limited to 76 Char/line>

User-pass = userid ":" Password

Userid = * <text excluding ":">

Password = * Text

Message example:

Request attempt:

Get. http: // 10.127.194.3: 8061/voiceobjects /...

Request Reply:

HTTP/1.1.401.unauthorized.date :. thu ,. 20. oct.2011.15: 16: 22. GMT .. server :. jetty/5.1.4. (SunOS/5.10.sparc.java/1.5.0 _ 15 .. WWW-Authenticate :. basic. realm = "vorealm ".. content-Type :. text/html .. content-Length :. 1249 .......

Request again:

Get. http: // 10.127.194.3: 8061/voiceobjects/sfdsdf. HTTP/1. 1 .. authorization :. basic. c2ljyxa6c2ljyxaxmjm = .. connection :. keep-alive .. HOST :. 10.127.194.3: 8061 .. content-Length :. 0 ....

Reply again:

HTTP/1.1.200. OK .date:. Thu,. 20. oct.2011.15: 12: 36. GMT... SERVER :.

 

Iii. authentication method:

The Digest authentication method is similar to the request authentication method, but the digest authentication method is more complex.

Before you begin, explain the expressions used in the explain Section:

H (data) = MD5 (data)

---- This indicates that data is encrypted using the MD5 algorithm.

KD (secret, data) = H (Concat (secret, ":", data ))

---- This indicates that secret and data are connected with the ":" And then encrypted using the MD5 algorithm.

---- Secret and data are both strings.

 

If the server replies 401, the following additional information should be included in Digest authentication:

Challenge = "Digest" digest-Challenge

 

Digest-challenge = 1 # (realm | [domain] | nonce |

[Opaque] | [stale] | [algorithm] |

[Qop-options] | [auth-Param])

 

Domain = "Domain" "=" <"> uri (1 * sp uri) <">

Uri = absoluteuri | abs_path

Nonce = "nonce" "=" nonce-Value

Nonce-value = quoted-string

Opaque = "Opaque" "=" quoted-string

Stale = "stale" "=" ("true" | "false ")

Algorithm = "algorithm" "=" ("MD5" | "MD5-sess" |

Token)

Qop-Options = "qop" "=" <"> 1 # qop-value <">

Qop-value = "auth" | "Auth-int" | token

The following explains the meaning of each value one by one:

A realm: similar to digest authentication.

B domain: is a list of Uri addresses enclosed by double quotes, each URI is separated by space, such as "http://www.baidu.com/value/index.html", it represents two addresses, one is the http://www.baidu.com, one is/value/index.html. Domain indicates the URI in which information contained in the returned 401 can be used?

C nonce: This is a very important value in Digest authentication. It is a string of base64 encrypted or hexadecimal strings generated by the server (this string be base64 or hexadecimal data ), in the digest authentication process, a different nonce value is returned each time the server generates 401. The standard recommends an algorithm: Time-stamph (time-stamp ":" etag ":" private-key). time-stamp is the time when the server produces nonce; etag is a way for HTTP to solve the cache mechanism. It is usually a strange string, but it can be used to indicate the version of the requested file. Private-key is a private key that only the server knows. Generally, every HTTP server has a configuration that can automatically generate the nonce value without writing code. The client must use this value to calculate the request content, which will be described below.

In addition, we can see that there will be a time drop in the nonce value. This time will also be used by the server to determine when the nonce was generated and has not expired yet? The client will include this value in the request information and send it to the server. The server gets this nonce value, decodes it, or does not decode it. The server will know how to handle this nonce generated by the server anyway, use the information it carries to determine whether the request is valid.

D opaque: A string specified by the server. The client sends a request in the same protected space (protection space is a bunch of connections using the same user name and password, you can return opaque to the server as it is.

E stale: Used to indicate whether the nonce in the previous request of the client has expired.

True:

Indicates that the user name and password are correct, but the nonce expires.

False:

This indicates that nonce is correct, but the user name and password are incorrect. In this case, the client needs to change the user name and password to resend the request (for IE, the dialog box for entering the user name and password is displayed ).

F algorithm: server and client algorithm conventions, generally MD5 or "MD5-sess ".

G qop-options: optional, generally "auth" or "Auth-int ". See the client algorithm section.

H auth-Param: used for future extension.

 

After the client receives the above information, it needs to re-Prepare the request message. The Digest authentication request message is as follows:

Credentials = "Digest" digest-Response

Digest-response = 1 # (username | realm | nonce | digest-Uri

| Response | [algorithm] | [cnonce] |

[Opaque] | [Message-qop] |

[Nonce-count] | [auth-Param])

 

Username = "username" "=" username-Value

Username-value = quoted-string

Digest-uri = "Uri" "=" digest-Uri-Value

Digest-Uri-value = request-Uri; as specified by HTTP/1.1

Message-qop = "qop" "=" qop-Value

Cnonce = "cnonce" "=" cnonce-Value

Cnonce-value = nonce-Value

Nonce-Count = "nc" "=" nc-Value

NC-value = 8 lhex

Response = "response" "=" request-Digest

Request-digest = <"> 32 lhex <">

Lhex = "0" | "1" | "2" | "3" |

"4" | "5" | "6" | "7" |

"8" | "9" | "A" | "B" |

"C" | "D" | "E" | "F"

A username: the username associated with a realm;

B digest-Uri: The request URI in the HTTP header. Copy it here. The purpose of copying is to modify the original URI through the proxy.

 

C qop: the value given by the server. If the server specifies several values, the client must select one. This field specifies the algorithm for calculating the response character.

D cnonce: if the server specifies qop, This value must be included in the request information. If the server does not specify qop, this value cannot be included. This value is a string specified by the client in its own way.

E nonce-count: if the server specifies qop, This value must be included in the request information. If the server does not specify qop, this value cannot be included. The number of times nonce was used, including this time. Is the number of times in binary format.

F response: This is the most important request information. Its calculation method is as follows:

If the "qop" value is "auth" or "Auth-int ":

Request-digest = <"> <KD (H (A1), unq (nonce-value)

":" Nc-Value

":" Unq (cnonce-value)

":" Unq (qop-value)

":" H (A2)

) <">

If the qop value is not specified:

Request-digest =

<"> <KD (H (A1), unq (nonce-value)": "H (A2)> <">

For A1 and A2, the calculation method is as follows:

A1:

If "algorithm" is MD5

A1 = unq (username-value) ":" unq (realm-value) ":" passwd

If "algorithm" is a MD5-sess, A1 is calculated only once in the first request of all requests after 401. The calculation method is as follows:

A1 = H (unq (username-value) ":" unq (realm-value)

":" Passwd)

":" Unq (nonce-value) ":" unq (cnonce-value)

 

A2:

If the qop value is "auth" or is not specified, then:

A2 = method ":" digest-Uri-Value

If the qop value is "Auth-int", then:

A2 = method ":" digest-Uri-value ":" H (entity-Body)

Method is an HTTP request method, such as "get" and "Post". You can refer to section 5.1.1 of the HTTP protocol document; digest-Uri-value = request-Uri; as specified by HTTP/1.1; entity-body in section 7.2 of the HTTP document.

 

Message example:

First time:

Get. http: // 10.119.244.39: 8099/voiceobjects...

Second:

HTTP/1.1.401.unauthorized.date :. wed ,. 08. dec.2010.17: 16: 17. GMT .. server :. jetty/5.1.4. (SunOS/5.10.sparc.java/1.5.0 _ 15 .. WWW-Authenticate :. digest. realm = "vorealm ",. domain = "/voiceobjects ",. nonce = "csp7xiwbaab4qgah08fxchbblha1zecy ",. algorithm = MD5 ,. qop = "auth ".. content-Type :. text/html .. content-Length :. 1249 ...........

Third time:

Get. http: // 10.119.244.39: 8099/voiceobjects/sdfsdfg. HTTP/1. 1 .. authorization :. digest. username = "ggggg ",. realm = "vorealm ",. nonce = "csp7xiwbaab4qgah08fxchbblha1zecy ",. uri = "/voiceobjects/dialogmappingauth ",. response = "2d2caa1d1043150281b61e92322a26d8 ",. algorithm = MD5 ,. qop = auth ,. NC = 00000001 ,. cnonce = "01343c114a9c5e842351ce3eaedc1ed1 ".. connection :. keep-alive .. HOST :. 10.119.244.39: 8099 .. content-Length :. 0 ....

Fourth:

HTTP/1.1.200. OK .date:. Thu,. 20. oct.2011.15: 12: 36. GMT... SERVER :...