+1 for this approach if possible. It seems possible (cannot tell exactly). Within SSLIOSessionHandler (httpcore), in the following method
*public void initialize(SSLEngine sslengine, HttpParams params) , * we can put application specific thing into SSLSession, then access within KeyManager implementation to pick the correct alias . BTW, the actual implementation of the X509ExtendedKeyManager is in * com.sun.net.ssl.internal.ssl*. Indika On Tue, Jul 21, 2009 at 4:11 PM, Andreas Veithen<[email protected]> wrote: > A quick look at the Javadoc shows that X509ExtendedKeyManager has > access to the SSLEngine from which the SSLSession can be retrieved. On > the other hand, SSLSession has methods getValue/putValue/removeValue > to store "application layer data". This could be a proper solution. To > be investigated. > > Andreas > > On Tue, Jul 21, 2009 at 12:32, Paul Fremantle<[email protected]> wrote: >> I agree. Maybe we could wrap the key manager and then be able to >> implement any kind of complexity (e..g multiple key stores, etc) >> behind that. The only question I have is whether you can pass context >> when you call across the key manager API. We need to pass some context >> so that the wrapper can do the right thing. Maybe thread local context >> would allow us to pass some context over that boundary. >> >> Paul >> >> On Tue, Jul 21, 2009 at 11:22 AM, Andreas >> Veithen<[email protected]> wrote: >>> On Tue, Jul 21, 2009 at 12:08, Hiranya Jayathilaka<[email protected]> wrote: >>>> Hi Folks, >>>> >>>> I did some testing using two Axis2 instances each using its own >>>> certificates. I managed to get Synapse to connect to both servers using a >>>> single truststore. I had to put both client certs as well as the CA cert in >>>> the Synapse truststore for this scenario to work. So I guess our current >>>> implementation is good enough for a great extent. >>>> >>>> However the problem I have is the way Synapse (or rather the Java SSL API) >>>> selects the client cert at runtime. As Andreas has mentioned it seems to be >>>> using some data sent by the server in selecting the correct client cert. I >>>> tried to find some documentation which properly explains this procedure but >>>> still couldn't find something satisfactory. However according to most >>>> resources and explanation provided by Oleg, it seems that client can decide >>>> which cert to present the way it wishes. In that case the above scenario >>>> might fail in certain situations. >>>> >>>> So IMHO the best option (most scalable and robust) we got is to implement a >>>> custom IOEventDispatch. WDYT? >>> >>> Personally, I think that the HTTP(S) transport is already complex >>> enough and that we should only add to that complexity if there is a >>> good reason to do so. Assuming that the client certificate selection >>> algorithm doesn't give the expected results, I think that implementing >>> a custom IOEventDispatch is only the second best solution. We should >>> first investigate the possibility to change the behavior of the key >>> manager. Since this is the component that selects the client >>> certificate, from a design perspective it would be the right place do >>> implement custom behavior. This approach would also have the advantage >>> of isolating the changes from the core of the transport. >>> >>> Andreas >>> >>>> Thanks, >>>> Hiranya >>>> >>>> >>>> >>>> On Tue, Jul 21, 2009 at 3:25 PM, Andreas Veithen < [email protected]> >>>> wrote: >>>>> >>>>> On Tue, Jul 21, 2009 at 11:30, Oleg Kalnichevski<[email protected]> wrote: >>>>> > On Tue, Jul 21, 2009 at 11:22:58AM +0200, Andreas Veithen wrote: >>>>> >> > Well, if not through different stores, how can we let the KeyManager >>>>> >> > know >>>>> >> > what cert to use for this particular endpoint? >>>>> >> >>>>> >> If I remember well, this is how it works: during the handshake, the >>>>> >> server presents a list of trusted CAs to the client. The client than >>>>> >> selects the certificate that is signed (directly or indirectly) by >>>>> >> that CA and uses that to authenticate. I'm pretty sure this is what >>>>> >> happens when you create a java.net.URL with the https scheme and call >>>>> >> openConnection on it. Since behind the scene this uses an SSLContext, >>>>> >> chances are high that it also works with our HTTPS transport (or that >>>>> >> it would be pretty easy to make it work). >>>>> >> >>>>> >> Of course this only satisfies the requirement if the two endpoints use >>>>> >> different CAs, which should be the usual case. >>>>> >> >>>>> >> Andreas >>>>> >> >>>>> > >>>>> > Hi Andreas >>>>> > >>>>> > I may be wrong about it but I believe the client can present whatever >>>>> > client >>>>> > cert it pleases. That cert does not _have_ to be signed by one of the >>>>> > trusted >>>>> > CA certs sent to client by the server. For instance, common browsers >>>>> > simply pop >>>>> > up a UI dialog and let you pick any client certificate available in the >>>>> > certificate store, if the server requests client authentication in the >>>>> > course >>>>> > of SSL context negotiation. >>>>> > >>>>> > Oleg >>>>> > >>>>> >>>>> That is possible, but it is only relevant for a scheme where the >>>>> consumer of the service creates a certificate himself (typically a >>>>> self-signed certificate) and somehow registers that with the provider >>>>> of the service. This implies that the provider has to manage a list of >>>>> recognized client certificates to authenticate the client. I don't >>>>> think that is a usual scheme for Web services (BTW, how would you do >>>>> that with Axis2?), but that it is more usual for the provider to issue >>>>> certificates to the consumer, so that authentication is based on the >>>>> signature on the client certificate. But again, this is a question >>>>> about the requirements. >>>>> >>>>> Andreas >>>>> >>>>> > >>>>> > >>>>> >> --------------------------------------------------------------------- >>>>> >> To unsubscribe, e-mail: [email protected] >>>>> >> For additional commands, e-mail: [email protected] >>>>> >> >>>>> > >>>>> > --------------------------------------------------------------------- >>>>> > To unsubscribe, e-mail: [email protected] >>>>> > For additional commands, e-mail: [email protected] >>>>> > >>>>> > >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> >>>> >>>> -- >>>> Hiranya Jayathilaka >>>> Software Engineer; >>>> WSO2 Inc.; http://wso2.org >>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>>> Blog: http://techfeast-hiranya.blogspot.com >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> >> -- >> Paul Fremantle >> Co-Founder and CTO, WSO2 >> Apache Synapse PMC Chair >> OASIS WS-RX TC Co-chair >> >> blog: http://pzf.fremantle.org >> [email protected] >> >> "Oxygenating the Web Service Platform", www.wso2.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
