synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Supporting Multiple SSL Configurations at Sender
Date Tue, 21 Jul 2009 10:41:33 GMT
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


Mime
View raw message