Do we have the required control of figuring out the right identity certificates over the endpoint in this approach?
For example can we provide the certificate to be used for a particular endpoint (may be as an alias) in the endpoint configuration? I guess that is the initial requirement. Ruwan On Tue, Jul 21, 2009 at 4:31 PM, indika kumara <[email protected]>wrote: > +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] > > > > > > -- Ruwan Linton Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: [email protected]; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
