axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Preston <PREST...@uk.ibm.com>
Subject Re: SSL implementation
Date Fri, 19 Nov 2004 09:51:49 GMT




Hi damitha,
      Excellent, I'll give it a go as soon as I can and pass back any
comments.

Best regards,

Fred Preston.
Software Engineer



                                                                                         
                                             
                      damitha kumarage                                                   
                                             
                      <damitha@opensour        To:       Apache AXIS C Developers List
<axis-c-dev@ws.apache.org>                      
                      ce.lk>                   cc:                                    
                                                
                                               Subject:  Re: SSL implementation          
                                             
                      19/11/04 07:16                                                     
                                             
                      Please respond to                                                  
                                             
                      "Apache AXIS C                                                     
                                             
                      Developers List"                                                   
                                             
                                                                                         
                                             




Hi Fred,
I have implemented an initial ssl implemenation and following I describe
the work I have done. I have attached the code as well for your
reference.

I have defined an api for pluggable ssl implementations for axis c++.
it is src/transport/SSLChannel.hpp(See attached code)

Then I have an implementation library called libaxis2_ssl_channel.so
which use
OpenSSL libraries. In this library I have OpenSSLChannel class which is
the
implemenation of the api I mentioned above. Inside this class methods I
have
method calls for openssl library implementation.
This library implementation(called ssl) folder comes under axis2 as a
sub folder.

There is no change in Axis2Transport and Channel classes.
I have introduced a new class called SSLChannelFactory which is
responsible
for loading the ssl implementation library using the following
information at
axiscpp.conf

Channel_ssl:/usr/local/axiscpp_deploy/lib/libaxis2_ssl_channel.so

So What SecureChannel class do is using the factory load the ssl channel
implementation
and calls methods of it. For example in open method I do
    Channel::open();
    m_pSSLChannel->openSSLConnection(&m_Sock);

I also changed configure.ac to allow the configure option to allow
building with
ssl support as following
configure --with-axis2-ssl=/usr/local/ssl
I also created the sample samples/client/ssl-client which uses the
simple service.
I tested this with apache server ssl enabled

thanks
damitha
On Fri, 2004-11-12 at 08:34, Samisa Abeysinghe wrote:
> Hi Fred / Damitha,
>
>     I have been thinking of IPV6 support for Axis C++.
>     I am yet to do a concrete design, but it looks to me that I would be
able to achieve the job
> by specilizing the Channel class to do IPV6 specific stuff and leave
Axis2Transport class as it
> is.
>
>     Going through your discussions on SSL support, I guess what you guys
also nees is a specilized
> Channel class to work with Axis2Transport. Axis2Transport class handles
more HTTP specific stuff,
> and gets the support from channel class to send them over to server side
(hence I think it is
> better to change the name).
>
>     Please take my requirement into account wehn you guys design the
class hierarchy for Channels.
>
> Thanks,
> Samisa...
>
>
> --- Damitha Kumarage <damitha@opensource.lk> wrote:
>
> > Hi Fred,
> > It seems that what I have in mind is somewhat different. Yet we are
closer
> > See below
> > >
> > >
> > >
> > >
> > > Hi Damitha,
> > >       I've been playing around with an implementation and have been
able
> > > to clarify a few ideas from yesterday's e-mail.  Let me run this past
> > > you to see what you think...
> >
> > I also have been playing around with another implementation and have
some
> > ideas as below
> >
> > >
> > > We need a generic way to implement other types of http transport,
such as
> > > SSL.  I want to minimise the amount of change to the existing
> > > Axis2Transport methods and to keep the code as reusable as possible.
The
> > > simplest way of doing this is to create a new object based on the
existing
> > > Channel object that has exactly the same public methods and will
interface
> > > with other, 'plugable' transport DLLs using a common API between the
new
> > > object and the DLL. i.e.
> >
> > agree
> >
> > >
> > > 1. Channel is the base object.
> >
> > ok
> >
> > > 2. PlugInSecureChannel is derived from Channel and is expecting to
load a
> > >    DLL with a common API  (C, non-decorated).
> >
> > In my case I thought of keeping SecureChannel derived from Channel and
> > inside the axis2 transport. In SecureChannel we load the pluggable dll
> > which implements a generic SSL api provided by Axis C++.
> > I Name this as SSLChannel and SSLChannel.h is placed in src/transport
> > along with SOAPTransport.h and it has following methods
> >
> > openSSLChanel
> > closeSSLChannel
> > sslRead
> > sslWrite
> > initSSL etc.
> >
> > In my ssl channel library I have C++ class derived from this interface
and
> > it has  open ssl 's C methods wrapped inside it. In addition it has dll
> > interface methods like create, destroy etc.
> >
> > I have Factory class called SSLChannelFactory which will load and
return a
> > SSLChannel object to the SecureChannel.
> >
> > SecureChannel's derived methods(From Channel) will call this instance
> > methods as neccessary to do ssl stuff.
> >
> > Any thoughts regarding this
> >
> > thanks
> > damitha
> >
> >
> >
> > > 3. SecureChannel is a DLL and is the implementation of the SSL over
HTTP
> > >    and exports its public methods through an API (C, non-decorated).
> > >
> > > So the DLLs is wrapped as follows:-
> > >
> > >                 .> PlugInSecureChannel -> (API) -> SecureChannel.dll
> > > Axis2Transport /   (derived from Channel)         (Implementation of
> > >                \                                   SSL over HTTP)
> > >                 .> Channel
> > >
> > > An example would be as follows:-
> > >
> > > A call to Axis2Transport.setEndpointUri() creates either a Channel or
> > > PlugInSecureChannel object depending on the supplied URL and then
calls
> > > m_pChannel->SetURL() on the instanciated object.  If the object is a
> > > PlugInSecureChannel object, then this call calls
> > > PlugInSecureChannel.SetURL()
> > > which in turn calls GetProcAddress( SecureChannelLibrary, "SetURL")
with
> > > the parameter list set to the URL.
> > >
> > > Below is a mapping from Channel object to library call...
> > >
> > > PlugInSecureChannel                            DLL API (so far...)
> > >
----------------------------------------------+-------------------------
> > > PlugInSecureChannel()                          Create()
> > > ~PlugInSecureChannel()                         Destroy()
> > > void setURL( const char *)
> > > void setURL( URL)
> > > const char * getURL()
> > > URL& getURLObject()
> > > bool open()                                    Open()
> > > void close()                                   Close()
> > > const Channel & operator >> ( string &)        Read( const char
*)
> > > const Channel & readNonBlocking( string&, bool)
> > > const Channel & operator << ( const char *)    Write( const char
*)
> > > const string & GetLastError()
> > > void setTimeout( unsigned int)
> > > void setSocket( unsigned int)
> > > void setMsgLength( int)
> > > int getMsgLength()
> > > char * getMsg()
> > >
> > > On the DLL side, what I've done is blended the C exported calls back
into
> > > a
> > > C++ object that is derived from the Channel class and overridden the
> > > methods that
> > > require additional SSL calls.  Thus I've ended up with a plugable
> > > SecureChannel
> > > that will not effect the operation of the existing unsecure Channel
> > > implementation.
> > >
> > > Regards,
> > >
> > > Fred Preston.
> > >
> > >
> > >
> > >
> > >                       damitha@opensourc
> > >                       e.lk                     To:       "Apache AXIS
C
> > > Developers List" <axis-c-dev@ws.apache.org>
> > >                                                cc:
> > >                       09/11/04 03:37           Subject:  Re: SSL
> > > implementation
> > >                       Please respond to
> > >                       "Apache AXIS C
> > >                       Developers List"
> > >
> > >
> > >
> > >
> > > Hi Fred,
> > >  I think now it is getting clear to me.
> > > I'll put it as I understood it.
> > >
> > > In SecureChannel we get the instance of ssl implementation(using a
ssl
> > > factory) that
> > > implements(through a wrapper) a ssl api provided by axis2 transport.
> > > In SecureChannel methods, this ssl instance's methods are called as
> > > necessary.
> > >
> > > The above mentioned ssl implementation is a shared library we need to
> > > write using libraries of a ssl implementation library(wrapping them).
Our
> > > SecureChannel will laod it using ssl factory.
> > >
> > > see below
> > >
> > >>
> > >>
> > >>
> > >>
> > >> Hi Damitha,
> > >>       I didn't want to create a new Axis2Transport class as this
would
> > >> lead
> > >> to code replication and the problems of supporting two or more
versions
> > > of
> > >> the what will largely be identical code.  I thought that the
simplest
> > >> way
> > >> to link in an additional secure transport would be to use the
existing
> > >> unsecure transport model and to add a secure channel stub/template
that
> > >> would link to a library (dll) with a generic API that would
implement
> > >> the
> > >> base set of functions (such as open, close, >>, <<, etc). 
The user
> > >> would
> > >> still be able to get and set transport properties for this transport
and
> > >> communicate with it in the same way as before.  The existing
> > >> Axis2Transport
> > >> object need only look at the beginning of the URL ('http://...' or
> > >> 'https://...') that it is passed to determine whether it needs to
open
> > >> an
> > >> ordinary, unsecure or secure channel (thus no flag passing is
required).
> > >>
> > >>   The SSL dll could still create an unsecure channel object to
handle
> > >> basic
> > >> transport operations, but would have the ability to extend the
operation
> > >> of
> > >> that object to suit its needs.
> > >>
> > >>            |
> > >>            V                  When Axis2Transport opens a
connection, it
> > >>      Axis2Transport           already knows the endpoint URI, thus
knows
> > >>      |            |           whether to open a normal or secure
> > >> channel.
> > >>      V            V
> > >>   Channel    SecureChannel    Assuming that it is a secure channel,
then
> > >>                   |           create a SecureChannel object (which
is
> > >> the
> > >>                   |           same as a Channel object).  When
> > >> Axis2Transport
> > >>                 (API)         calls methods on the secure channel
> > >> object,
> > >>                   |           they are routed down through the
generic
> > >>                   |           'SSL API' to the underlying library
that
> > >>                   |           implements the SSL API.
> > >>                   V
> > >>                SSL.dll        The SSL.dll may create its own
instance of
> > >> the
> > >>                               base unsecure Channel
> >
> === message truncated ===
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Check out the new Yahoo! Front Page.
> www.yahoo.com
>
>
>










#### SecureChannel.cpp has been removed from this note on November 19 2004
by Fred Preston
#### SSLChannelFactory.cpp has been removed from this note on November 19
2004 by Fred Preston
#### SSLChannelFactory.hpp has been removed from this note on November 19
2004 by Fred Preston
#### OpenSSLChannel.cpp has been removed from this note on November 19 2004
by Fred Preston
#### OpenSSLChannel.hpp has been removed from this note on November 19 2004
by Fred Preston
#### SSLChannelLoader.cpp has been removed from this note on November 19
2004 by Fred Preston
#### Makefile.am has been removed from this note on November 19 2004 by
Fred Preston
#### SSLChannel.hpp has been removed from this note on November 19 2004 by
Fred Preston


Mime
View raw message