Since I have attacked it from a Yoko perspective, I have created a
full-blown (or rather half-blown, since its not yet complete) ssl
transport plugin. This means that Yoko creates the SSL sockets using a
specified configuration.
In Yoko, the existing IIOP transport is implemented as a plugin. The
IIOP transport can be configured globally. In addition, it is possible
to create a POAManager with a specific EndpointPolicy.
The SSL transport plugin should be configured similarly:
SSLEndpointConfig cfg = new SSLEndpointConfig();
cfg.setRequireConfidentiality(true);
cfg.setRequireIntegrity(true);
cfg.setRequireTrustServer(true);
cfg.setCipherSuite(ciphers);
cfg.setPort(1234);
// ... additional endpoint configuration
EndpointConfigurationPolicy policy = new
EndpointConfigurationPolicy(cfg.toConfigString());
Policy[] policies = new Policy[] {policy};
POA rootPoa = ...
Policy[] poaPolicy = ...
POAManager poaManager = managerFac.create_POAManager("name", policies);
POA poa rootPoa.create_POA("SSLEnabledPOA", poaManager, poaPolicy);
I will also create a way to define endpoint configuration globally for
the ORB.
Would this work for Geronimo? I think it is preferable that sockets are
created by the ORB. In any case, I definitely think we should to be able
to do SSL without Geronimo.
I have not yet figured out how to do key management.
Additionally, we have some portable interceptors from the Trifork ORB.
I'm not exactly into what they are doing yet, except they handle
security stuff above the transport level. They are fully portable, so
perhaps we can make use of them. I'll check them into the repo later today.
Best regards,
Anders
Rick McGuire wrote:
Whoa, we really need to be careful we don't make any duplicate work
here. I have already spent some efforts on figuring out whats needed
on Yoko's part. I have started implementing SSL transport in a
seperate plugin though. Perhaps we should coordinate our efforts.
Sounds good to me. At this point, you certainly understand how the
current Yoko code works, and I've got a very good understanding of what
Geronimo requires. I've gotten as far as figuring out what this plugin
needs to look like from the Geronimo standpoint. Basically, the
Acceptor_impl and Connector_impl classes implemented calls to the plugin
wherever it was necessary to create a Socket or ServerSocket. Here's
the default plugin code I came up with for when nothing has been
overridden:
// **********************************************************************
//
// Copyright (c) 2005-2006
// IONA Technologies PLC
// Dublin, Ireland and Waltham, MA, USA
//
// All Rights Reserved
//
// Licensed to apache under Apache 2.0 License - 2006
// **********************************************************************
package org.apache.yoko.orb.OCI.IIOP;
import java.io.IOException;
import java.net.ConnectException;
import java.net.InetAddress;
import java.net.Socket;
import java.net.ServerSocket;
import org.omg.CORBA.Policy[];
import org.omg.IOP.IOR;
public class DefaultSSLHelper implements SSLHelper {
public void init(String[] parms) {
// no initializer parameters required by this version.
}
public Socket createSocket(IOR ior, Policy[] policies, InetAddress
address, int port) throws IOException, ConnectException {
return new Socket(address, port);
}
public ServerSocket createServerSocket(int port, int backlog, boolean
sll) throws IOException, ConnectException {
if (ssl) {
return
SSLServerSocketFactory.getDefault().createServerSocket(port, backlog);
}
else {
return new ServerSocket(port, backlog);
}
}
public ServerSocket createServerSocket(int port, int backlog,
InetAddress address, boolean ssl) throws IOException, ConnectException {
if (ssl) {
return
SSLServerSocketFactory.getDefault().createServerSocket(port, backlog,
address);
}
else {
return new ServerSocket(port, backlog, address);
}
}
}
The server SLL configuration is specified as a transport plugin property
set up by the ORB instantiator, the client socket configuration decision
is made using the information encoded in the ior (which requires the use
of Geronimo stored information).
There are a couple of issues I haven't addressed yet in what I've done:
1) How the loading of the plugin gets specified when the ORB is
initialized (and the loading process itself). In particular, the
Geronimo version of this plugin is going to need to pass at least one
initialization argument in to the plugin so it can reestablish a
connection to the configuration information for the ORB instance.
2) The Acceptor_impl class has a bit of code that does a "connect to
self" operation. In this situation, the client socket configuration is
determined by the server socket configuration, but another callback is
required in the plugin so that the socket gets created using Geronimo's
socket factories.
3) Geronimo is going to need to be able to retrieve access to the used
socket in a ServerRequestInterceptor so it has access to the SSL
session information. For both the Sun and IBM ORBs, this is done using
an extended version of the ServerRequestInfo class (which is admittedly,
non portable). For example, here's a snippet from the Sun version:
public void receive_request_service_contexts(ServerRequestInfo ri) {
if (log.isDebugEnabled()) log.debug("Looking for SSL Session");
RequestInfoExt riExt = (RequestInfoExt) ri;
Connection connection = riExt.connection();
if (connection != null) {
Socket socket = connection.getSocket();
if (socket instanceof SSLSocket) {
if (log.isDebugEnabled()) log.debug("Found SSL Session");
SSLSocket sslSocket = (SSLSocket) socket;
SSLSessionManager.setSSLSession(ri.request_id(),
sslSocket.getSession());
}
}
}
Rick
Best regards,
Anders
