I didn’t look details at code level of patch. Patch is an implementation of approach that uses MultiworkerIOReactor per SSLContext .
Reactor is the heart of the Reactor pattern. It is all about scalability. Generally, multiple reactors use for load balance between reactors to match CPU and IO rates. By default, we use a MultiworkerIOReactor which is a multi reactor implementation. In above patch we use collections of MultiworkerIOReactors. I don’t know how much resources it consumes. A system with n users to be scalable, the quality of physical resources required to support them should be at most O(n). Therefore, without increasing in loads, if physical resources consumption is increased, it is not a scalable system. BTW, this will be only needed by some set of users. General users may not be affected. Therefore, usually there will be a one MultiworkerIOReactor. So, this approach may be an option. But, it depends on actual users that need this feature. Would they like to have many MultiworkerIOReactors in a Single Server? If they like, this solution may be OK. Please look at following doc which is from Javadoc of ‘AbstractMultiworkerIOReactor’. <javadoc> *Generic implementation of that can run multiple instances in separate worker threads and distribute newly created I/O session equally across those I/O reactors for more optimal resource utilization and a better I/O performance. Usually it is recommended to have one worker I/O reactor per physical CPU core.* <javadoc> It is better to *ask from Oleg*?. He has written all these core codes. If he thinks this is OK, then I believe, this approach may be OK. Indika On Tue, Jul 21, 2009 at 8:56 PM, Ruwan Linton <[email protected]>wrote: > 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 >
