Passing SSL connection details to application

[kwaclaw]

I am currently finishing off an SSL plugin for IceCS (C#).
One of the things I would like to do is pass client certificate
information for a connection to the application, that is,
through Ice.Current.con().

Now, a generic way to do so would be to add an (opaque)
member to Connection, such as (in C# syntax):

    
    public interface _ConnectionOperationsNC
    {
        ...
        object info();  <-- new member
    }

This would also require to add the same kind of new member
to the Transceiver interface, and the method implemention
in the ConnectionI class would be:

        public object info()
        {
            return _transceiver.info();
        }

My Transceiver implementation (SslTransceiver in this case)
can then implement its info() method in any way it sees fit.

All the application needs to do is cast the object back
to a known type. Example (I modified the Hello server to
show the name on the client certificate):

    public override void sayHello(Ice.Current current)
    {
        string msg = string.Empty;
        SslStream ssl = current.con.info() as SslStream;
        if (ssl != null) {
            X509Certificate cert = ssl.RemoteCertificate;
            msg = cert.Subject + " says: ";
        }
        msg += "Hello World!";
        System.Console.Out.WriteLine(msg);
    }

Does that make sense to anyone?

Karl

[mes]

Hi,

Providing this type of information is on our TODO list, but we don't have an estimate on when it will be included in a release.

I realize you're probably trying to find a way to do this without changing the Ice core, but I think a better approach is something like this:

// Slice
interface TransportInfo {
    string toString();
};
interface X509Certificate { ... };
interface SslTransportInfo extends TransportInfo {
    X509Certificate getCertificate();
    ...
};
interface Connection {
    TransportInfo getTransportInfo();
    ...
};

Naturally, this is more complicated, because now we have to wrap the X509 information. But at least it's portable and fits within the Ice object model.

By the way, the next release of Ice for C# will include the thread-per-connection concurrency model, which will be necessary if the SslStream class in .NET 2.0 cannot be used with the thread-pool model.

Take care,
- Mark

[kwaclaw]

I realize you're probably trying to find a way to do this without changing the Ice core, but I think a better approach is something like this:

// Slice
interface TransportInfo {
    string toString();
};
interface X509Certificate { ... };
interface SslTransportInfo extends TransportInfo {
    X509Certificate getCertificate();
    ...
};
interface Connection {
    TransportInfo getTransportInfo();
    ...
};

Naturally, this is more complicated, because now we have to wrap the X509 information. But at least it's portable and fits within the Ice object model.

I agree with the TransportInfo interface. However, there could be multiple plugins for Ssl - one relying on .NET framework, another relying on OpenSSL. Each may have some unique information to expose not present in the other. Therefore it might be better to simply allow the plugin to define the derived interface instead of constraining the information one can pass with a predefined SslTransportInfo definition.

By the way, the next release of Ice for C# will include the thread-per-connection concurrency model, which will be necessary if the SslStream class in .NET 2.0 cannot be used with the thread-pool model.

I have to admit I do not fully understand the implications of the ICE thread-pool model. From what I can see from the source, _transceiver.write() calls are serialized through a mutex. So should it then matter that SslStream is not thread-safe?

Is the Session demo a good way to test the thread-pool model with SslStream?

Karl

[mes]

Hi,

In my contrived example, plugins would define their own derived interfaces.

Regarding the thread pool: I'm not familiar with the SslStream functionality in .NET 2.0, but you mentioned it only supported blocking operations. The thread pool uses non-blocking sockets, so it's quite possible that the thread pool will not behave properly when using an SslStream. There is a similar situation in Java, because the SSL interfaces in J2SE 1.4 do not support select-style functionality, therefore the IceSSL plugin for Java can only be used in thread-per-connection mode.

- Mark

[kwaclaw]

Hi,
In my contrived example, plugins would define their own derived interfaces.

OK, I was thinking the same.
I have it working right now like you suggested.

So, I am able to get at lower level information to extract client
authentication info. That is fine if the SSL endpoint is at the server.

Now I am faced with a more general problem:
What if I use Glacier2? The server will not have an SSL endpoint
directly connected to the client anymore.

I haven't been able to figure out a way how the existinig Glacier2 would
be able to forward such client credentials information.

And even if it was modified to somehow add information to the
context, this would not be an elegant solution, as the server now would
have *two* ways to access that info, either using the TransportInfo
interface, or reading the context.

This almost looks like the proper way would be to establish some
"secure circuit" between client and server, regardless of underlying
transport. But then the use of SSL would be redundant.
There is an OMG spec called SECP, but it appears quite complex.

Regarding the thread pool: I'm not familiar with the SslStream functionality in .NET 2.0, but you mentioned it only supported blocking operations. The thread pool uses non-blocking sockets, so it's quite possible that the thread pool will not behave properly when using an SslStream. There is a similar situation in Java, because the SSL interfaces in J2SE 1.4 do not support select-style functionality, therefore the IceSSL plugin for Java can only be used in thread-per-connection mode.
- Mark

So far it works for me.

Karl