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]
