The WSO2 SOA Enablement Server provides HTTP basic and digest authentication, specified in IETF's : HTTP Authentication: Basic and Digest Authentication. These authentication mechanisms are used when a Web service uses HTTP as a transport layer. HTTP basic and digest authentication are simple challenge-response authentication mechanisms that may be used by a server to challenge a client request, and by a client to provide authentication information.
In a client/server application model, clients initiate action and servers respond. Typically, a server listens at a communications port waiting for clients to connect and ask for a service. In this scenario, users without credentials are prompted to supply a username and password. These are returned to a server where they become available to the application.
With basic authentication, the Web service client authenticates with a user name and password, which is then Base64-encoded and passed to the server. The server verifies the received user information against the user store on the Web service server. The weakness of the basic authentication mechanism is that user information encoded by the Base64 method is very easily decoded.
Digest authentication also uses a challenge-response authentication mechanism as basic authentication. However, digest authentication does not actually pass the username and password over the Internet. Instead, a one-way encryption method is employed to authenticate the user with a hash value. This is clearly more secure than basic authentication.
Because basic authentication involves the clear text transmission of passwords, it should not be used (without enhancements) to protect sensitive or valuable information. The more secure method is combining basic authentication with SSL. Both Basic and Digest authentication are vulnerable to "man in the middle" attacks, for example, from a hostile or compromised proxy.
To use basic and digest authentication, information about users on the server side is stored in the user store. An application on the client side must authenticate to the system, thus providing a username and password, which are stored in the Credentials object. The user information is then used when a client application tries to look up or invoke the Web service. A user must have a password attribute stored in the user store on the server side.
Basic authentication is a standard HTTP authentication mechanism that uses clear text (data that is transmitted as clearly readable text characters) to send and receive user security information. Basic authentication offers minimal protection for securing your application data. Using this type of authentication, user credentials are encoded but not encrypted, and are thus vulnerable to detection by anyone able to sniff network packets. We recommend using HTTP basic authentication only in combination with SSL.
Basic Authentication Scheme.
Upon receipt of an unauthorized request, the server responds with a challenge like the following:
WWW-Authenticate: Basic realm="RealmString"
where "RealmString" is the string assigned by the server to identify the protection space.
To continue with communication, the client has to send the user ID and password, separated by a single colon (:) character, within a base64-encoded string. If the user agent wishes to send the user ID "Aladdin" and password "open sesame", it would use the following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Steps to Use HTTP Basic Authentication
On the server side:
Create a user entry: Set the password attribute to the user using the UserStoreTool
Set the accepting security provider to "HttpBasic"
On the client side:
Set the security provider to "HttpBasic"
Authenticate with the username, password and "HttpBasic" security provider
Unlike basic authentication, which forwards clear-text user names and passwords from client to server, digest authentication uses encryption when forwarding secure password information between clients and servers on the network. Passwords are not transmitted over the network.
The following HTTP Digest Provider Preferences can be set by the user: Algorithm, Context Time-to-Live, Quality of Protection, and Sweep Interval. These are set in the Server Preferences tab of the Administration Console; see Server Preferences Management.
Digest Authentication Scheme (simplified).
If a server receives a request and an acceptable authorization header is not sent, the server responds with a "401 Unauthorized" status code and a WWW-Authenticate header that contains a uniquely generated nonce. For example:
HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="HttpDigestAuthentication http://waspserver:6060/secure/hello/", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"
Client responses should contain a header with a checksum of the username, the password, the given nonce value, the HTTP method, and the requested URI. In this way, the password is never sent in clear text. For example:
Authorization: Digest username="Mufasa", realm="HttpDigestAuthentication http://waspserver:6060/secure/hello/", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/secure/hello/", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"
Steps to Use HTTP Digest Authentication
On the server side:
Create a user entry. Set the password attribute to the user using the UserStoreTool.
Set accepting security provider to HttpDigest.
On the client side:
Set the security provider to HttpDigest.
Authenticate with the username, password, and the security provider HttpDigest.