synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruwan Linton <ruwan.lin...@gmail.com>
Subject Re: Supporting Multiple SSL Configurations at Sender
Date Tue, 21 Jul 2009 15:26:21 GMT
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 <indika.kuma@gmail.com>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 <hiranya911@gmail.com
> > wrote:
>
>>
>>
>> On Tue, Jul 21, 2009 at 5:42 PM, indika kumara <indika.kuma@gmail.com>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 <ruwan.linton@gmail.com>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 <indika.kuma@gmail.com>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<
>>>>> andreas.veithen@gmail.com> 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<pzfreo@gmail.com>
>>>>> 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<andreas.veithen@gmail.com> wrote:
>>>>> >>> On Tue, Jul 21, 2009 at 12:08, Hiranya Jayathilaka<
>>>>> hiranya911@gmail.com> 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 <
>>>>> andreas.veithen@gmail.com>
>>>>> >>>> wrote:
>>>>> >>>>>
>>>>> >>>>> On Tue, Jul 21, 2009 at 11:30, Oleg Kalnichevski<
>>>>> olegk@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>>>> >>>>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>> >>>>> >>
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> ---------------------------------------------------------------------
>>>>> >>>>> > To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>> >>>>> > For additional commands, e-mail: dev-help@synapse.apache.org
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>>
>>>>> >>>>>
>>>>> ---------------------------------------------------------------------
>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>> >>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> Hiranya Jayathilaka
>>>>> >>>> Software Engineer;
>>>>> >>>> WSO2 Inc.;  http://wso2.org
>>>>> >>>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>>>>> >>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> ---------------------------------------------------------------------
>>>>> >>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Paul Fremantle
>>>>> >> Co-Founder and CTO, WSO2
>>>>> >> Apache Synapse PMC Chair
>>>>> >> OASIS WS-RX TC Co-chair
>>>>> >>
>>>>> >> blog: http://pzf.fremantle.org
>>>>> >> paul@wso2.com
>>>>> >>
>>>>> >> "Oxygenating the Web Service Platform", www.wso2.com
>>>>> >>
>>>>> >>
>>>>> ---------------------------------------------------------------------
>>>>> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>> >>
>>>>> >>
>>>>> >
>>>>> > ---------------------------------------------------------------------
>>>>> > To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>> > For additional commands, e-mail: dev-help@synapse.apache.org
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ruwan Linton
>>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>>> WSO2 Inc.; http://wso2.org
>>>> email: ruwan@wso2.com; cell: +94 77 341 3097
>>>> blog: http://ruwansblog.blogspot.com
>>>>
>>>
>>>
>>
>>
>> --
>> Hiranya Jayathilaka
>> Software Engineer;
>> WSO2 Inc.;  http://wso2.org
>> E-mail: hiranya@wso2.com;  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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Mime
View raw message