synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiranya Jayathilaka <hiranya...@gmail.com>
Subject Re: Supporting Multiple SSL Configurations at Sender
Date Mon, 20 Jul 2009 14:02:57 GMT
On Mon, Jul 20, 2009 at 6:34 PM, Andreas Veithen
<andreas.veithen@gmail.com>wrote:

> Hiranya,
>
> Before discussing the implementation, could you please explain the use
> case?


I have posted a link to a forum discussion in SYNASPE-563. You can get a
rough idea of the requirement by going through the discussion there.

In short this is the usecase we are trying to support. Lets say a user wants
to proxy a set of web services using Synapse. Each web service is exposed
over HTTPS and hence all the endpoint definitions in the Synapse config will
be https endpoints. Instead of using a single key store to connect to each
https endpoint we want to use different key stores. My proposal is a
mechanism to select keystores at endpoint level.

Thanks,
Hiranya


>
> Andreas
>
> On Mon, Jul 20, 2009 at 14:47, Hiranya Jayathilaka<hiranya911@gmail.com>
> wrote:
> > Hi Folks,
> >
> > I'm working on an enhancement which enables us to specify multiple SSL
> > configurations for the HTTPS transport sender and refer to such
> > configurations at the endpoint level (See SYNAPSE-563 for a problem
> > description). Then we'll be able to use different SSL configurations when
> > connecting to different endpoints. This is how I propose to implement
> this
> > feature.
> >
> > 1. We introduce the concept of SSL profiles to the HTTPS transport
> sender.
> > Then in the axis2.xml, under https transport sender configuration, we can
> > have the usual SSL configuration and optionally a set of SSL profiles.
> The
> > below sample shows an https configuration with one profile definition
> > (called myprofile).
> >
> > <transportSender name="https"
> > class="org.apache.synapse.transport.nhttp.HttpCoreNIOSSLSender">
> >         <parameter name="non-blocking" locked="false">true</parameter>
> >         <parameter name="keystore" locked="false">
> >             <KeyStore>
> >                 <Location>lib/identity.jks</Location>
> >                 <Type>JKS</Type>
> >                 <Password>password</Password>
> >                 <KeyPassword>password</KeyPassword>
> >             </KeyStore>
> >         </parameter>
> >         <parameter name="truststore" locked="false">
> >             <TrustStore>
> >                 <Location>lib/trust.jks</Location>
> >                 <Type>JKS</Type>
> >                 <Password>password</Password>
> >             </TrustStore>
> >         </parameter>
> >     <parameter name="customSSLProfiles">
> >         <!-- We can have zero or more profiles defines here -->
> >         <profile name="myprofile">
> >             <KeyStore>
> >                 <Location>/home/hiranya/cert/service.jks</Location>
> >                 <Type>JKS</Type>
> >                 <Password>abc123</Password>
> >                 <KeyPassword>abc123</KeyPassword>
> >             </KeyStore>
> >             <TrustStore>
> >                 <Location>/home/hiranya/cert/client.jks</Location>
> >                 <Type>JKS</Type>
> >                 <Password>abc123</Password>
> >             </TrustStore>
> >         </profile>
> >     </parameter>
> > </transportSender>
> >
> > 2. We create SSL contexts for each profile and the default SSL
> > configuration, during sender initialization and associate each SSL
> context
> > with an IOReactor instance. All the IOReactors except for the default one
> > would be stored in a map keyed by its corresponding profile name.
> >
> > 3. We make it possible to specify a SSL profile at endpoint definition
> level
> > as follows.
> >
> > <endpoint>
> >          <address
> > uri="https://localhost:9002/services/SimpleStockQuoteService">
> >              <sslProfile>myprofile</sslProfile>
> >         </address>
> > </endpoint>
> >
> > 4. The Axis2FlexibleMEPClient will set the profile name as a message
> context
> > property when sending messages using endpoint definitions.
> >
> > 5. At the transport level we retrieve the property and lookup the map to
> > find an IOReactor to send the message (if the property is not set we use
> the
> > default IOReactor)
> >
> > As far as the transport is concerened all the heavy work of creating SSL
> > contexts and IOReactor objects will happen during transport
> initialization.
> > Only runtime overhead would be the effort made to check the message
> context
> > property for a SSL profile name.
> >
> > I already have some working code implementing this and would love to
> > contribute it. But before I do I would like to know what the Synapse team
> > thinks about implementing this feature in the suggested manner. Your
> > feedback is most appreciated.
> >
> > Thanks,
> > --
> > 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
>
>


-- 
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

Mime
View raw message