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 09:29:21 GMT
Anders Hessellund Jensen wrote:
> Rick McGuire wrote:
>> I've already started work on seeing if I can get this to work, 
>> attacking it from what Geronimo requires from an ORB in terms of 
>> callbacks to manage the SSL security.  This required creation of a 
>> small plugin to the iiop plugin to allow Geronimo to participate in 
>> the security decision making and also hook in to the Geronimo 
>> keystore management and configuration process.
>
> 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