Javadoc
An implementation of the DigestCallback that support the http digest auth as
described in RFC2617 (http://www.ietf.org/rfc/rfc2617.txt).
3.2.2.1 Request-Digest
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" directive is not present (this construction is for compatibility
with RFC 2069):
request-digest = < KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
See below for the definitions for A1 and A2.
3.2.2.2 A1
If the "algorithm" directive's value is "MD5" or is unspecified, then A1 is:
A1 = unq(username-value) ":" unq(realm-value) ":" passwd
where
passwd = < user's password >
If the "algorithm" directive's value is "MD5-sess", then A1 is calculated only
once - on the first request by the client following receipt of a
WWW-Authenticate challenge from the server. It uses the server nonce from that
challenge, and the first client nonce value to construct A1 as follows:
A1 = H( unq(username-value) ":" unq(realm-value) ":" passwd ) ":"
unq(nonce-value) ":" unq(cnonce-value)
This creates a 'session key' for the authentication of subsequent requests and
responses which is different for each "authentication session", thus limiting
the amount of material hashed with any one key. (Note: see further discussion
of the authentication session in section 3.3.) Because the server need only use
the hash of the user credentials in order to create the A1 value, this
construction could be used in conjunction with a third party authentication
service so that the web server would not need the actual password value. The
specification of such a protocol is beyond the scope of this specification.
3.2.2.3 A2
If the "qop" directive's value is "auth" or is unspecified, then A2 is:
A2 = Method ":" digest-uri-value
If the "qop" value is "auth-int", then A2 is:
A2 = Method ":" digest-uri-value ":" H(entity-body)
3.2.2.4 Directive values and quoted-string
Note that the value of many of the directives, such as "username- value", are
defined as a "quoted-string". However, the "unq" notation indicates that
surrounding quotation marks are removed in forming the string A1. Thus if the
Authorization header includes the fields
username="Mufasa", realm=myhost@testrealm.com
and the user Mufasa has password "Circle Of Life" then H(A1) would be
H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks in the
digested string.
No white space is allowed in any of the strings to which the digest function H()
is applied unless that white space exists in the quoted strings or entity body
whose contents make up the string to be digested. For example, the string A1
illustrated above must be
Mufasa:myhost@testrealm.com:Circle Of Life
with no white space on either side of the colons, but with the white space
between the words used in the password value. Likewise, the other strings
digested by H() must not have white space on either side of the colons which
delimit their fields unless that white space was in the quoted strings or entity
body being digested.
Also note that if integrity protection is applied (qop=auth-int), the
H(entity-body) is the hash of the entity body, not the message body - it is
computed before any transfer encoding is applied by the sender and after it has
been removed by the recipient. Note that this includes multipart boundaries and
embedded headers in each part of any multipart content-type.