incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: Milestone release
Date Wed, 24 May 2006 11:11:41 GMT
Anders Hessellund Jensen wrote:
> 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.
No, this would not work for Geronimo.  Geronimo has a KeystoreManager 
functionality that is used to configure/manage various keystore 
configurations, which are then hooked up with services that need to 
create SSL sockets.  The KeystoreManager handles details of where the 
trust stores and key stores are located, unlocking the stores, 
identifying appropriate keyAliases, etc.  A given server configuration 
may have multiple KeystoreManager instances, each managing multiple 
keystore/truststore combinations.  Each individual ORB instance we end 
up creating will be given it's own keystore configuration (which is 
managed by calls into the KeystoreManager API).  Because of the need to 
make calls back into the keystore manager, this is not something that 
can be managed using static properties. The ORB will, at a minimum, need 
to retrieve the appropriate socket factory via a Geronimo callback in 
order for this to work.

Also, a static configuration like you've described only works for the 
listener sockets.  For client connections, the Geronimo needs to be 
involved in the decision-making process on whether to use a plain or 
secure connection based on profile information stored in the IOR.  It 
also uses that IOR information to determine authentication and cipher 
suite configuration.  This needs to be determined on a per-connection 
instance, and again requires cooperation with Geronimo services to work.

> I have not yet figured out how to do key management.
Geronimo has an API for doing key management...we just need to figure 
out how to allow it to be involved.  That was the purpose of the 
SSLHelper plugin I've been working on.

>
> 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.
Geronimo has a number of portable interceptors as well, but this one 
particular item didn't appear to be doable using just portable 
interceptors.

Rick

>
> 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
>>>
>>
>
>


Mime
View raw message