Please read this documentation while looking at the classes in this package and also the JmxConnectorLifeCycle class in /m/jws/appserv-core/src/Java/calm/sun/enterprise/Adm./server/core. I know there are many many Server and Client SocketFactories, but none of them has accompanying documentation and hence there is one more pair. More information is provided here, because these classes are difficult to understand (ssl itself is) and then on top of it, we have to understand how the whole thing fits in application server land. The entire complexity comes because of the fact that we have one single jmx-connector-server in the configuration of DAS that serves connection from internal clients as well as external clients. The internal client is: Node agent and other server instances. The external clients are configured by customers (potentially). Here is how the jmx-connector that is started in DAs as a life cycle module looks like in the domain.xml:
<jmx-connector accept-all="false" address="escher.red.iplanet.com" auth-realm-name="Adm.-realm" enabled="true" name="system" port="8686" protocol="rmi_jrmp" security-enabled="true"> <ssl cert-nickname="s1as" ssl3-enabled="true" tls-enabled="true" client-auth-enabled="false"/> <property name="client-hostname" value="escher.red.iplanet.com"/> </jmx-connector>
Note that the security-enabled flag (which determines whether the connection will be over SSL) is true by default on SE/EE and false by default on PE. (This is the decision as of 07/17/2004). Thus out of the box the security-enabled is false for PE and true for SE/EE. If on PE the security-enabled is changed to true, then this functionality is exactly same as that on EE. The same connector server is used by both node agent/server instance clients and external clients. It is important to understand the use of classes in this package in this regard.
Note that these classes will be used only when the internal clients are concerned. These classes are used while creating the client and server SSL sockets while following communications happen:
Here are the classes:
This factory creates the SSLServerSocket that knows how to obtain the keystore password (pluggably), truststore implementation and so on. This is the only thing that needs to be used while creating the SSLServerSocket. An instance of this class is sent as an element in the environmental map to the RMIConnectorServer Class as the RMI_SERVER_SOCKET_FACTORY_ATTRIBUTE and then it handles the internals from there on. I have tried to reuse the existing TrustManager. This SocketFactory is on the server side and does not need to be standardized.
This class sets up the client side environment. In the complex world of 8.1 EE, we have every server and client entity as a client. For instance, DAS is a server, but it is also a client to node agent and other server instances in certain key areas. Server instances other than DAS itself are clients to DAS and node agent is a client of server instance and DAS. All the VM's have to set this environment up so that the SSL client side works properly. A few instances where this class is used as of $Date: 2005/05/27 22:53:46 $ that I know are:
Since, when the server end of the RMI Connector Server is created, we have to pass both the Client and Server Socket Factories in the environmental map. Now, there has been an attempt to standardize these factories. The only problem is that for the J2SE 1.5 is required as these factories are standardized there. (Date: 07/16/2004). I may choose to use these factories when running atop J2SE 1.4. These classes are staged along with the remote jmx RI (rjmx-ri) in the jar rmissl.jar.
Thus the most important point is that this client factory has to be standard, otherwise standard JSR 160 clients can not connect without using the java.rmi.server.codebase system property and installing a SecurityManager. Hence I am abandoning the use of such an appserver specific RMI Client Socket Factory in favor of the to-be-standard SslRMIClientSocketFactory.
Thus, AdminSslClientSocketFactory in this package is not used while trying to set up the server end of "system" JMX Connector. This is why you see following in JmxConnectorLifeCycle.java:
final RMIServerSocketFactory sf = new AdminSslServerSocketFactory(sslc);
final RMIClientSocketFactory cf = new AdminRMISSLClientSocketFactory(); // From
MBeanAPI
driver.setRmiServerSocketFactory(sf);
driver.setRmiClientSocketFactory(cf);
The AdminSslServerSocketFactory would be used as above as the same server end will get connector by external JSR 160 clients. User code has to use its own client socket factory as it is the one that knows how to establish the trust by using its own TrustManager. This is explained in a more detailed manner in the MBean API documentation. More often than not, the users will use the AppserverConnectionSource class in the MBean API to connect to server rather than connecting using the standard JSR 160 classes/interfaces. There are a few things that the appserver administrative clients through MBean API will have to do in order to connect to the "system" JMX Connector in SE/EE over RMI/SSL.
The external clients have to do something similar to what is done in AsTlsClientEnvSetter class.
@see JSSE Documentation
@since Application Server 8.1
@author Kedar.Mhaswade@Sun.Com