Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change notification.
The following page has been changed by RolandWeber: http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedApplicationDesignQuestions The comment on the change is: added section about client authentication techniques ------------------------------------------------------------------------------ ---- [[TableOfContents]] - ---- + ------- == Sending Parameters and Uploading Files == A question that is asked on a regular basis is: @@ -168, +168 @@ [http://java.sun.com/javaee/5/docs/api/javax/mail/package-summary.html Java Enterprise Edition 5.0, JavaMail API] + + + + ------- + == Client Authentication == + + There are different techniques by which a client can establish + it's identity to a server in a web environment. + We repeatedly got questions from users who were not aware of + the differences between those techniques. + This section presents the common authentication techniques and + puts them in the appropriate context. + + === Protocol Layers === + + Whenever a web client communicates with a web server, there + are communications on different protocol layers. The following + diagram shows the layers relevant for this discussion: + + ||<:>Application Layer|| + ||<:>HTTP Layer|| + ||<:>Transport Layer|| + + At the top, there is the application layer. That is your + client application communicating with a web application. + The web application can for example be comprised of some + servlets and JSPs. Your application will create and send + requests and interpret the responses to achieve some + purpose specific to your application. + [[BR]] + The middle layer is where HTTP communication takes place. + That is HttpClient or HttpComponents (or + [http://java.sun.com/j2se/1.5.0/docs/api/java/net/HttpURLConnection.html java.net.HttpURLConnection]) + exchanging HTTP messages with an HTTP server. !HttpClient + is not aware of the purpose of the messages. It merely + knows how to generate and parse the HTTP message format, and + how to handle some HTTP protocol details such as redirects and cookies. + [[BR]] + At the bottom is the transport layer. That is the operation system + connecting sockets to the computer on which the HTTP server is running. + Or it is a TLS/SSL library creating a secure connection to that computer. + On this layer, it is just binary data passing between the machines. + The transport layer is not aware of the data being HTTP messages, + let alone of the purpose for which the application is communicating. + + This layered structure is not obvious to the casual user. + When using a browser, you don't care whether your input is + interpreted by the HTML engine on the application layer, + or by the HTTP implementation on the HTTP layer, or by + the TLS/SSL implementation on the bottom layer. + Likewise, if you are developing a web application for example + in a J2EE environment, you're looking at the protocol layers + from the top down and don't care where the functionality is + provided. + [[BR]] + However, !HttpClient is [wiki:Self:ForAbsoluteBeginners not a browser]. + If you are developing an application with !HttpClient or + some other HTTP implementation, you have to be aware of this structure. + Client authentication can be performed on each of the three layers, + but !HttpClient is only responsible for the middle layer. + You will need to use other APIs for authentication on the application + or transport layer. + + + === Basic, Digest, NTLM Authentication === + + These authentication techniques operate on the HTTP layer and are + supported to some degree by HttpClient. + Basic and Digest authentication are specified in + [http://www.ietf.org/rfc/rfc2617.txt RFC 2617]. + Both are fully supported by !HttpClient. + A browser will typically pop up an authentication dialog asking + for the password to a specific server. The password will be asked + only once for each session. If NTLM authentication is used and + the password is the same as the Windows password, there may be + no authentication dialog at all (single sign-on, SSO). + + Basic authentication is considered insecure because it sends the + user password in plain text (unprotected) with each request. + That is only acceptable to some degree in intranets or when using + TLS/SSL secure connections (HTTPS). It is generally not acceptable + when using insecure connections over the internet. + [[BR]] + Digest authentication is more secure than basic authentication + because the password itself is not sent to the server. Instead, + a hash of the password is created and sent. Digest authentication + is rarely used, since in order to verify the hash, the server + needs to know the user password in plain text. User repositories + will typically not store passwords in plain text, but rather + hashes of the password. Therefore, digest authentication can + not be performed using such repositories. Storing passwords in + plain text on the server backend systems introduces a weak spot + into the server side architecture. + [[BR]] + NTLM authentication comes in several varieties, all of which are + proprietary authentication protocols by Microsoft. !HttpClient + partially supports NTLM authentication, as explained in the + [wiki:Self:FrequentlyAskedNTLMQuestions NTLM FAQ]. + The older versions, or lower levels, of NTLM authentication suffer + from the same weakness as Basic authentication. The newer versions + rectify this, but the protocols are not publicly documented. + There are no open source implementations of the newer versions. + + + === Form Based Authentication === + + The form based authentication technique operates on the application layer. + When using a browser, username and password have to be entered + in an HTML form. They will be sent to the server only once. + After successful authentication, the server remembers that this + client is authenticated and will not ask for the password again + during that session. Session tracking often requires a cookie. + [[BR]] + From the HttpClient perspective, submitting a form for client + authentication is no different from submitting a form for a + search query or any other purpose. + Instructions on how to support session tracking and simulate + form submission are available in the + [wiki:Self:ForAbsoluteBeginners Client HTTP Programming Guide]. + + Form based authentication is more secure than basic authentication. + Although it also transmits the password in plain text, it does so + only once and not with every request. Still, when used over the + internet, from based authentication should use a secure TLS/SSL + connection at least for the login procedure. Afterwards, the session + can be continued over plain connections, as the password is not + sent again. + + + === Certificate Based Authentication === + + Certificate based (client) authentication operates on the transport layer. + It is part of the TLS/SSL protocol. Instead of using a password, + certificate based authentication relies on public key cryptography. + A private key is stored on the client and used to authenticate + against the server. + A browser will typically pop up a password dialog, asking for the + password to the local key store. The password is never sent to the + server, it is only used locally to gain access to the private key. + The private key itself is never sent either. + [[BR]] + From the HttpClient perspective, certificate based authentication + is performed transparently when a secure TLS/SSL connection is + established to a server. Transparently means that !HttpClient doesn't + know anything about the authentication at all. You have to install a + [http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/protocol/SecureProtocolSocketFactory.html SecureProtocolSocketFactory] + that automatically authenticates the client if requested by the server. + This includes asking the user for the password to the local key store. + + Certificate based client authentication is the most secure of the + authentication techniques discussed here. The drawback is that it + requires a complex public key infrastructure + ([http://en.wikipedia.org/wiki/Public_key_infrastructure PKI]) + to be put in place. + Certificates holding the public keys for each client need to be + available in the server's user repository, and the private keys + have to be deployed on each client machine. Issuing the certificates + for all clients is itself a complex task. + + + === Further Reading === + + [http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Overview6.html The J2EE 1.4 Tutorial, Security] (SUN) + + [http://www.ietf.org/rfc/rfc2617.txt RFC 2617: HTTP Authentication: Basic and Digest Access Authentication] + + [http://www.onjava.com/pub/a/onjava/2002/06/12/form.html J2EE Form Based Authentication] (onJava.com) + + [http://en.wikipedia.org/wiki/Public_key_infrastructure Wikipedia: Public Key Infrastructure] + + [http://www.ietf.org/rfc/rfc2246.txt RFC 2246: The TLS Protocol Version 1.0] + + [http://www.ietf.org/rfc/rfc3546.txt RFC 3546: Transport Layer Security (TLS) Extensions] + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
