The Secure Sockets Layer (SSL) is an important component of WebLogic's security framework. J2EE applications deployed to WebLogic can rely on SSL to maintain data integrity and confidentiality of communications at the socket level. SSL-enabled clients also can rely on SSL to verify the identity of the server. In fact, if the server is configured for two-way SSL, it also may verify the client's identity. SSL can be used to secure communications between the Administration Server and the various Managed Servers in a WebLogic domain. Node Managers that monitor the health of all Managed Servers running on a single machine must communicate over the SSL port.
Let's consider some typical scenarios in which SSL can protect network communication between two parties:
All of these scenarios require you to properly configure SSL on the particular WebLogic instance. WebLogic supports SSL on a dedicated listen port, which defaults to 7002. Thus, a web browser (or any client) can securely interact with a configured WebLogic instance via a URL connection to https://server:7002/.
SSL configuration requires a little more effort than just enabling HTTPS traffic on port 7002. As we shall see, SSL relies on a public-key encryption technology that uses a combination of two keys: a private key that is known only to the owner, and a public key that is embedded in a digital certificate. In fact, WebLogic comes equipped with demonstration keys and certificates that are used to verify the server's identity when a client establishes an SSL connection with the server. While these may be sufficient for development purposes, you should configure WebLogic with a production-quality private key and digital certificate. Later, we explain how to generate the server's private key and a request for a digital certificate to be issued by a certificate authority (CA).
For added security, WebLogic lets you store the server's private key, public certificate, and certificates of all trusted CAs in a keystore. We examine how you can create and configure these keystores. Trusted CA certificates are an essential requirement of SSL setup because they allow a party to trust the other party's certificate presented during the initial SSL handshake. We also look at how to extend two-way SSL configuration by mapping the client certificate to a WebLogic user, which effectively lets you use certificates as a form of user identity.
Finally, we look at how to build Java clients that use WebLogic's SSL implementation to access SSL-protected resources. For instance, a client can establish an SSL session by making a URL connection to a JSP page deployed on another WebLogic instance. A web browser may be required to present a valid certificate as proof of its identity when attempting to access a protected web resource over the SSL port. A Java client that needs to establish an initial JNDI context with a WebLogic instance can do so securely using the T3S protocol, optionally sending a digital certificate to prove its identity. These are just some of the ways in which SSL can protect network communication in a WebLogic environment.
WebLogic supports the Java Authentication and Authorization Service (JAAS), Java Secure Sockets Extensions (JSSE), and Java Cryptography Extensions (JCE). It recognizes digital certificates in the X.509 v3 format, and its SSL implementation conforms to the SSL 3.0 and TLS 1.0 standards.
Besides SSL, WebLogic provides a modular security infrastructure that controls many other aspects of security. These features include connection-level filtering, server-side authentication and authorization, and interdomain trust. We cover these issues in the next chapterhowever, we touch on one or two here.
Managing the Web Server
Using JNDI and RMI
Using CMP and EJB QL
Packaging and Deployment
Performance, Monitoring, and Tuning
Logging and Internationalization