Menu
Recently we've been working on a project that integrates our Tomcat web server with a couple specific services on a mobile device. One of the things we can do during our interaction with the device (which is over HTTP) is get the device to prompt the user for credentials. After the user has entered their credentials, our server receives an HTTP post that contains the standard HTTP digest authentication headers (Authorization header with nonce, realm, response, etc). No big surprises there.
Our server (by design) doesn't actually contain the passwords for any users. We keep a SHA512 hash of their password. For local users we can start to store the MD5 of the "username:realm:password" when the log in to the application. Is that a common way of dealing with digest auth when you don't store the password?
More importantly we interact with LDAP servers via some JNDI code we've written for authentication. Because the device is forced to authenticate with our server via http and digest is the only supported authorization method, we can't really seem to find a way to use the digest response to authenticate the user via LDAP. Conceptually it doesn't really seem right that you would be able to "proxy" a digest request either. Is there a workflow out there that would allow for this type of "pass through" authentication and if so is it even a good idea?
Thanks!
222
Digest authentication allows users to authenticate based on user name and password without sending the user name and password as clear text. The browser uses the MD5 algorithm to create a digest value using the users password and some information provided by the Proxy Server.
Digest authentication is another authentication type specified in HTTP 1.1. Unlike basic authentication, digest authentication does not require the password to be transmitted. Rather, the client takes the username and password and uses the MD5 hashing algorithm to create a hash, which is then sent to the SQL Server.
qop. This parameter MUST be used by all implementations. It is a quoted string of one or more tokens indicating the "quality of protection" values supported by the server. The value "auth" indicates authentication; the value "auth-int" indicates authentication with integrity protection.
BasicAuthenticationFilter is responsible for processing basic authentication credentials presented in HTTP headers. This can be used for authenticating calls made by Spring remoting protocols (such as Hessian and Burlap), as well as normal browser user agents (such as Firefox and Internet Explorer).
One approach could be using simple authentication over HTTPS between the client and your server, then using the password against the LDAP server. You don't need to store the password, as it will be provided by the client on each login. For instance, you may verify the password against the stored SHA512(password), and then pass the clear password to the LDAP server.
If you cannot use HTTPS, or the server is not trusted for knowing the password, things are more complicated, because you cannot compute the SASL response from the provided MD5 digest (unless the LDAP server uses the DIGEST-MD5 mechanism, which is obsolete). In that case, you could proxy the whole SASL authentication exchange between the LDAP server and your client, and have the client send the responses via AJAX. Then, knowledge of the password will be restricted to the client.
121
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
