Even when using IOEventDispatch (What I suggested as my first solution), we have to get information from IOSession to pick correct Cert- possibly remote domain name and ip. These things can get from SSLSession too - may be more.
BTW, simple approach is best if it solves the problem. Any way, X509ExtendedKeyManager is in com.sun.net.ssl.internal.ssl , it may be an issue to wrap this class. So , IOEventDispatch solution may be only feasible one. Indika On Tue, Jul 21, 2009 at 5:23 PM, Ruwan Linton <[email protected]>wrote: > 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 >
