Hi All,
We currently have Basic auth to support secure endpoints in API
Manager. We hope to provide a "Digest auth facility" as well, in our next
release 1.10, in order to ensure better security.
In this feature, the client(The API Developer) will have the
ability to select the authentication type he or she requires as either
Basic auth or Digest auth.
If the client selects Digest auth as the preferred authentication
type, the password is never sent over the network in plain text whenever
the client requests access to a resource. What we send is only a hash.
The following diagram explains the digest authentication process in a
nut shell.
I will further explain it here.
1. The client sends a request to the backend for accessing the resource.
2. The backend receives the request and sends back a 401 Authentication
required message indicating that the client’s request has generated an
unauthorized access error.
3. Then the client extracts the required information from the message sent
by the backend and generates hashes as shown by the source code below.
HA1 = md5(username:realm:password)
HA2 = md5(requestMethod:uri)
Hash = md5(HA1:serverNonce:nc:cnonce:qop:HA2)
The * realm* is a string which is used as part of the hash. It is the name
of the domain that contains the account indicated by the user name.
The *qop*(Quality Of Protection) can be one of auth, auth-int etc. and has
influence on how the hash is created. We use auth here.
The *serverNonce* is a unique code, which is used within the hash and needs
to be sent back by the client to the backend.
The above are the essential information gathered from the 401 response sent
by the backend.
Then the *username* and the *password* supplied by the client, the realm,
the serverNonce and the qop sent by the backend are used for the creation
of the hash along with the following as well.
The *nc* is the Nounce count which is a hexadecimal serial number for the
request. The client should increase this number by one for every request.
It is the number of times the client has sent a challenge response by using
the nonce. The nonce must be specified if a "qop" directive is sent.
The * cnonce* is a unique id generated by the client. This nonce represents
a challenge issued by the client to the server when immediate
authentication of the server is desired. It can also be used to chosen
plain text attacks.
The *uri* is the authentication uri of the requested resource and the *request
method* can be one of GET, POST, etc.
4. The final Hash generated here is then sent to the backend for
authentication, incorporated in an authentication header along with the
following content.
The username, realm, serverNonce, uri, qop, nc and cnonce. Note that the
password is not sent along with these information.
5. Then the backend will respond accordingly with respect to the validity
of the authentication.
The hash cannot be decrypted. Therefore the backend does this check by
applying the same hashing procedure with the password stored in the
database of the backend. If the hashes match, access is granted to the
requested resource.
Tharika Madurapperuma
Software Engineering Intern
WSO2
Mobile : +94777-875-624
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
