If it is going to require IOEventDispatcher changes and a KeyManger impl that is too complex...
Why don't we be concrete and have a look at the patch provided and try to overcome the drawbacks of the implementation (if there are any)? Asankha/Oleg, can you please have a look at the patch? Thanks, Ruwan On Tue, Jul 21, 2009 at 6:03 PM, indika kumara <[email protected]>wrote: > I didn’t investigate the details of any suggested solution. Just said what > comes in to my mind. Possible approaches for complete solution may be based > on OEventDispatch and Keymanger. > You can go deep and suggest what the easy yet complete solution is. Then, > everyone will agree with that. > > Indika > > On Tue, Jul 21, 2009 at 5:56 PM, Hiranya Jayathilaka <[email protected] > > wrote: > >> >> >> On Tue, Jul 21, 2009 at 5:42 PM, indika kumara <[email protected]>wrote: >> >>> 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. >> >> >> The X509ExtendedKeyManager abstract class comes from the javax.net.ssl >> package. It's implementations are JDK specific. But technically that >> shouldn't prevent us from wrapping it. Need to dig deeper into the API to >> get a clear idea on this. >> >> Thanks, >> Hiranya >> >> >>> >>> 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 >>>> >>> >>> >> >> >> -- >> Hiranya Jayathilaka >> Software Engineer; >> WSO2 Inc.; http://wso2.org >> E-mail: [email protected]; Mobile: +94 77 633 3491 >> Blog: http://techfeast-hiranya.blogspot.com >> > > -- 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
