13.3 Using the SSL Support Built into J2EE Products

 <  Day Day Up  >  

The SSL protocol has a very important role in J2EE security. The SSL support built into a J2EE product helps reduce the burden on programmers, because SSL can be declaratively activated when the communication between the client and the server needs to be protected. In this section, we see when SSL protection should be turned on to guarantee privacy, data integrity, authenticity, and nonrepudiation.

13.3.1 SSL to Protect User ID and Password during Authentication

In a J2EE environment, user authentication is a fundamental security issue. One of the most common forms of user authentication requires a user to authenticate by submitting to the server a valid user ID and password pair. J2EE products support two methods of authentication based on user ID and password: HTTP authentication and form-based authentication.

With HTTP authentication, the user ID and password are transmitted as part of an HTTP header. There are two HTTP basic authentication modes: basic , if user ID and password are transmitted as cleartext, and digest , if a hash value of the password, rather than the password itself, is transmitted to the server.

With form-based authentication, the server retrieves the user ID and password information from the client through an HTML form. The user ID and password are transmitted as cleartext.

Therefore, with HTTP basic authentication and form-based authentication, it is highly recommended that, to protect the confidentiality of the credentials, the authentication transaction take place over an HTTPS connection. Note that with these forms of authentication, SSL is not used to authenticate the client but only to protect the communication between the client and the server. For this reason, it is not necessary for the server to require client authentication. Typically, in these scenarios, user ID and password information is transmitted over an SSL session with server-side authentication only. Protecting the authentication transaction with SSL can be done declaratively, using the support for SSL built into the J2EE product.

J2EE also supports Java clients that allow the user ID and password to flow across an IIOP message. Using the CSIv2 protocol (see Section 3.3 on page 61), the user ID and password pair is in a GSSUP token within the CSIv2 ESTABLISH_CONTEXT message. In order for this communication to be protected, transport-level SSL is recommended.

13.3.2 SSL in Certificate-Based Authentication

As we discussed in Section 13.1.2 on page 452, when a Web server is configured to require client authentication over SSL, the client and the server mutually authenticate by using each other's digital certificates. The certificates are exchanged during the SSL handshake.

In a public-key cryptosystem, the private key of a client is known only to its owner. The private key stays with the client and is never sent over the network, and it is its owner's responsibility to ensure that no one can have access to it. Therefore, the possession of a private key is a valid form of client authentication. A successful negotiation of an SSL connection between the client and the server implies that the client's certificate is signed by a CA trusted by the server and that the client who presented the certificate possesses the private key corresponding to the public key wrapped in the client certificate. As a client's certificate is associated with a specific principal on the client side, the client's certificate in a successful SSL handshake is considered a valid form of client authentication.

The client-certificate contents can be used to derive the identity of the requester. The SSL server uses the client's digital certificate to represent a unique user, a group of users, or an organization. This way, client digital certificates can be used to infer the identity of the clients and to prove authenticity when performing authorization checks.

In a J2EE environment, it is possible to set the authentication method for a Web application to be certificate based by declaratively configuring the deployment descriptor in the Web application's Web module. This can be done by setting the auth-method element in the login-config descriptor to the value CLIENT-CERT , as shown in Listing 4.7 on page 121.

After a successful certificate-based authentication, the client's identity information is available to programs running on the J2EE product. Those programs can use that information to customize the level of security in relation to the client's identity. For example, based on the identity of the client, a servlet may enforce a specific level of access control or may interact with an enterprise bean to retrieve information on that specific client from a database. In Section 4.8.3 on page 140, we showed that the Java Servlet API allows servlets to retrieve several pieces of information about the client's identity, such as

  • The client's digital certificates and digital certificates of all the CAs in the certificate chain

  • The size of the key used to establish the SSL connection

  • The cipher suite used to establish the SSL connection

An example of a servlet retrieving client-identity information after a successful certificate-based authentication is shown in Listing 4.19 on page 141.

13.3.3 Reverse Proxy Server and WAS Mutual Authentication

Several enterprise topologies are designed in such a way that an SSL connection is established between a client and a secure reverse proxy server located in a demilitarized zone (see Section 2.2 on page 29 and Section 6.2.4 on page 195). In such environments, it is the reverse proxy server that participates in the SSL handshake. The J2EE Web application server designated to handle the requests from the client does not participate in the handshake.

Therefore, the reverse proxy server is responsible for authenticating the client by deriving the client's identity from the client's digital certificate. Subsequently, the reverse proxy server transmits the client's identity information to the WAS designated to handle the requests from the client. Therefore, two security issues need to be addressed.

  1. The client's identity information should be encrypted while in transit between the reverse proxy server and the WAS.

  2. A trust relationship between the reverse proxy server and all the WASs in the clustered environment must be properly designed.

Both of these requirements are met in a declarative way by establishing a mutual-authentication SSL connection between the reverse proxy server and each WAS in the clustered environment.

SSL support is also useful when two WASs need to exchange confidential information. For example, there may be clustered WASs sharing the same Web contents and load balanced by a dispatcher machine. In this case, client session information needs to be shared across the WAS nodes to prevent loss of authentication information. To obtain data confidentiality and integrity on untrusted networks, SSL can be turned on. This scenario is depicted in Figure 13.2.

Figure 13.2. Using SSL in a J2EE Clustered Topology

graphics/13fig02.gif

13.3.4 SSL in Cookie-Based Single Sign-On

As we observed in Section 4.5.2 on page 123, when the authentication method is form based, SSO can be achieved by setting an HTTP cookie with authentication information on the client system (see Section 4.10.2.1 on page 148). For data confidentiality and integrity reasons, SSL should be used when this type of SSO is required. An SSL connection prevents unauthorized parties from acquiring the token from the network flow and guarantees data integrity.

The safest approach is to ensure that an SSL connection is established every time a cookie is created and stored on the client. This assurance can be obtained declaratively by properly configuring the server. Similarly, an SSL connection should be active every time the authentication information stored in the cookie is transferred from the client to the server. This second requirement can be met by making the cookie secure , which means that its Secure attribute is set. The client interprets this as an indication that the cookie should be sent back to the server only by using a secure protocol, such as HTTPS or SSL.

13.3.5 Single Sign-On with Certificate-Based Authentication

If authentication is certificate based, a single SSL connection is maintained across multiple HTTPS requests. Therefore, the client's identity information is available on every request, and there is no need to prompt the user to resubmit it every time. SSO in these scenarios is implicitly guaranteed by the fact that all the HTTP requests are carried over the same SSL session.

The only problem with this approach is when an enterprise includes multiple organizations, each having its own HTTP server belonging to a different Domain Name Service system. In this case, an SSL session between a client and a server cannot be transferred from that server to another. The second server should engage in a new SSL handshake with the client, at which point the user at the client system will be required to resubmit authentication information as part of the client's certificate. Therefore, the SSO intrinsically supported by certificate-based authentication cannot be used in these environments.

13.3.6 SSL to Protect the Communication Channel

So far, we have seen how SSL can be declaratively used in a J2EE environment to protect authentication information. However, SSL was designed and implemented primarily to protect any type of security-sensitive information flowing between a client and a server, not only authentication data. For example, credit card or social security numbers entered on an HTML form should not be transferred as cleartext from a client to a server. Data confidentiality, integrity, authenticity, and nonrepudiation are essential requirements with these types of transactions. There are two possible ways to meet these requirements: to secure the communication channel in a declarative way and to protect the data using cryptography in a programmatic way.

The second approach requires special client-side capabilities that may not be available in a Web browser environment. The first approach ”to secure the communication channel in a declarative way ”is obtained by using SSL. In a J2EE environment, a Deployer can specify that the URL request for a particular Web application must be accessed only over a secure channel by properly configuring the Web application's deployment descriptor in the Web application's Web module. This can be done by setting the transport-guarantee element in the user-data-constraint descriptor to INTEGRAL or CONFIDENTIAL , as shown in Listing 4.12 on page 133. In this case, the Web container will redirect the request to be resubmitted over HTTPS, enforcing integrity and confidentiality on the transport layer of the communication between the client and the server. As we observed in Section 3.10.1.2 on page 92, the values INTEGRAL and CONFIDENTIAL are treated as equivalent; they both indicate the requirement for an SSL connection.

 <  Day Day Up  >  


Enterprise Java Security. Building Secure J2EE Applications
Enterprise Javaв„ў Security: Building Secure J2EEв„ў Applications
ISBN: 0321118898
EAN: 2147483647
Year: 2004
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net