Could use custom marshaller to put extra information into the invocation payload (which is basically what the InvocationUnMarshaller does). However, in this particular case, it won't work because the marshaller/unmarshaller are only passed the stream and not the actual transport object itself. So need to get the info from the SSLSocket, which is not accessible within the unmarshaller.

I've created jira issue for this in remoting (JBREM-298)

Have added support for adding a HandshakeCompletedListener to the remoting code, so can now get callback when ssl session handshake finished (per JBREM-314).

Still need to add support at the invocation layer (per JBREM-298). However, am not sure how (or even if) this should really be done. Ideally, would like this behavior to be introduced via an interceptor that the user could add. Only problem is that the ejb invoker does not expose a way to do this currently. Any ideas on a generic way to do this?

As of JBossRemoting 2.0.0 (scheduled for release later this month) and already in CVS HEAD, can add a HandshakeCompletedListener via the following code:

 Map config = new HashMap();
 config.put(Client.HANDSHAKE_COMPLETED_LISTENER, myHandshakeListener);

 InvokerLocator locator = new InvokerLocator(getTransport() + "://" + host + ":" + port);
 client = new Client(locator, "mock", config);
 client.connect();

Well, remoting is not going to provide direct access to the socket itself without writing providing a custom implementation of the socket wrapper class and setting it via config (i.e. using clientSocketClass config property). However, if user does provide a HandshakeCompletedListener to remoting client, as stated above, they will then be able to prevent the client from making a call on the socket associated with the handshake callback (by just thowing an exception out of the handshakeCompleted() method). How/why they would do this, I don't care (or need to)... just want to allow them the ability to do this.

So, I think remoting is in good shape in regards to the behavior needed. Now need to know how to integrate this higher up the stack (like in ejb invocation) or if this is even something I need to be responsible for?

In the long run, I am wondering, will we have testcases to validate binary security tokens on the server side with client side population? The binary tokens include x509 certificates, kerberos tickets, xml tokens(some forms) etc.

How about a generalization of HandshakeCompletedListener:

 interface SocketCreatedListener
 {
 void socketCreated(Socket socket);
 }

 SocketCreatedListener listener = ... ;
 HashMap config = new HashMap();
 config.put(Remoting.SOCKET_CREATED_LISTENER, listener);
 Client client = new Client(locator, config);

 SocketCreatedListener listener = ... ;
 HashMap config = new HashMap();
 config.put(Remoting.SOCKET_CREATED_LISTENER, listener);
 Connector = new Connector(locator, config);

I have implemented a version of the solution I suggested above and checked it in to the Remoting HEAD and remoting_2_x branches.

1. There are a couple of changes. First, the listener interface, org.jboss.remoting.socketfactory.SocketCreationListener, is

public interface SocketCreationListener
{
 /**
 * Called when a socket has been created.
 *
 * @param socket socket that has been created
 * @param source SocketFactory or ServerSocket that created the socket
 * @throws IOException
 */
 void socketCreated(Socket socket, Object source) throws IOException;
}