Ruwan , It is not reactors that proportional to the users , but all resources consumes by reactors. Did you see java doc from ‘AbstractMultiworkerIOReactor’.
<javadoc> *Usually it is recommended to have one worker I/O reactor per physical CPU core.* <javadoc> I believe because It is few SSL profiles this may be acceptable. But , It is better to get feedback from some one using Synapse in a real production environment. Indika On Wed, Jul 22, 2009 at 6:12 AM, Ruwan Linton <[email protected]>wrote: > Indika, > > This might not be the approach that we need to do but I just wanted to get > concrete in this discussion and see how we can implement this. I agree with > you, this might not be a scalable solution but on the other hand we will > have only a few SSL profiles, but not many in a given server.. so we are not > talking about hundreds of reactors it will be like 3-5, also it is not > proportional to the users in the system. > > Thanks for the review and I think this is very valuable. Hiranya, I suggest > we wait for few other reviews and do the modifications to the code so that > we gets to the sub optimal solution. You may investigate on the > IOEventDispatcher approach in the mean time as well. > > Thanks, > Ruwan > > > On Tue, Jul 21, 2009 at 11:34 PM, indika kumara <[email protected]>wrote: > >> 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 >>> >> >> > > > -- > 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 >
