This chapter is from the book
This chapter is from the book
This chapter is from the book
3.11 Secure Communication within a WAS Environment
A fundamental aspect of any distributed computing system is remote communication. In an enterprise environment, components, such as Web servers, plug-ins, and WASs; external servers, such as LDAP directory servers; and clients communicate with one another over multiple protocols.
-
HTTP clients invoke URL requests to Web servers over HTTP.
-
WASs communicate with one another over IIOP.
Listing 3.19. Getting a Connection to an EIS with Container-Managed Sign-On
// Method in an application component Context initctx = new InitialContext(); // Perform a JNDI lookup to obtain a ConnectionFactory javax.resource.cci.ConnectionFactory cxf = (javax.resource.cci.ConnectionFactory) initctx.lookup ("java:comp/env/eis/MyEIS"); // Insert here the code to get a new ConnectionSpec com.myeis.ConnectionSpecImpl props = // ... // Set user ID and password props.setUserName("bobsmith"); props.setPassword("db2foobar"); // Invoke the ConnectionFactory to obtain a connection. // The security information is passed explicitly to the // getConnection() method. javax.resource.cci.Connection cx = cxf.getConnection(props); -
Some WASs may communicate with external systems by using other protocols. For instance, a WAS can communicate with an LDAP directory server over LDAP.
Because these components can host and distribute security-sensitive information, it is necessary to provide secure communication channels. The quality-of-service (QoS) should include encryption, integrity, and, possibly, authentication. The SSL protocol is generally used to meet these QoS requirements. Typically, two modes of SSL connections are used in J2EE:
-
Server-side SSL. The client connects to the server and attempts to verify the authenticity of the server's identity. The server does not verify the client's identity. If the client can authenticate the server successfully, the client/server communication is performed over an encrypted channel.
-
Mutual-authentication SSL. The client connects to the server. Both client and server attempt to authenticate to each other. If the mutual-authentication process is successful, client and server communicate over an encrypted channel.
The SSL configuration on the server side dictates whether a client connecting to the server should connect over server-side SSL or mutual-authentication SSL. In both cases, the strength of encryption depends on the configured cipher suite. In a Java environment, JSSE-compliant SSL providers are used to establish secure communication using SSL between the end points (see Chapter 13 on page 449).
The following list shows possible combinations of securely communicating parties:
-
Web client to Web server. Any Web browser can issue a request to a Web server over a secure connection. This communication can be over either server-side SSL or mutual-authentication SSL. The Web server should be configured to accept connections from Web browsers over a secure-socket port—typically, port 443. If a WAS requires a client to present a client certificate in order to be authenticated to access a servlet, the underlying Web server should be configured to require mutual-authentication SSL connections from Web browsers. This configuration is specific to the underlying Web server that is used, whereas the client certificate information is configured on the Web browser and is specific to the browser settings.
-
Web server to WAS. In general, a Web server needs a plug-in to communicate with a back-end WAS, unless the Web server and the WAS are integrated to form a single component. In a typical scenario, a Web server plug-in may communicate with an application server over HTTP. This can be configured to be over SSL, in which case the resulting protocol is HTTPS. In order for this to happen, the WAS transport must be configured to accept only secure connections. In the case of mutual-authentication SSL, the WAS transport can also be configured to trust only a set of selected clients to connect to the WAS. By properly configuring the digital-key storage facility—for example, a key file—both the plug-in and the WAS can be configured to accept a list of trusted Certificate Authorities (CAs), so that a trusted communication link can be established with only the clients whose certificates have been authenticated by one of the trusted CAs (see Section 10.3.4 on page 372).
-
WAS to WAS. WASs communicate to other WASs by using IIOP. In a secure environment, all these communications are over SSL. The digital-key databases can be configured to reflect the trust policy by using the tools provided with J2EE. In general, it is also possible to configure the strength of encryption enforced in such a secure connection.
-
Application client to WAS. Similar to a Web browser's making a request to a Web resource, Java clients can use the EJB programming model to invoke methods on an enterprise bean by connecting to the WAS that hosts the enterprise bean. In a secure environment, the communication from the client to the protected resources should be protected by the SSL protocol. At that point, an application client can securely communicate with a WAS over SSL. This is achieved by configuring the WAS with a list of trusted application clients. Alternatively, the WAS can be configured to accept a list of trusted CAs, so that a trusted communication link can be established with only the application clients whose digital certificates have been authenticated by one of the trusted CAs.
-
WAS to LDAP directory server. A WAS may need to connect to external systems. For example, a WAS may be configured to use an LDAP directory server as a user registry. In this case, the WAS will make calls against the LDAP directory. The protocol of communication between these two entities is LDAP. User ID and password pairs are verified by performing LDAP bind operations against the LDAP directory. In a scenario like this, these values will flow over the wire unencrypted unless the communication is protected by the SSL protocol. For this reason, an LDAP directory server should be configured to require that all connections be over SSL. The set of digital certificates trusted by the directory server can be imported into the WAS's digital-key storage facility so that the WAS can successfully establish an SSL connection with the LDAP directory server.