axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Damitha Kumarage" <dami...@opensource.lk>
Subject Re: SSL implementation
Date Thu, 11 Nov 2004 12:18:16 GMT
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
>
> What do you mean by saying, SSL.dll may create its own instance of base
> unsecure channel?
>
>
>> object to use generic
>>                               function such as opening and closing
> sockets
>>                               and/or sending and receiving messages,
>> etc.
>> Regards,
>>
>> Fred Preston.
>>
>>
>>
>>
>>                       damitha@opensourc
>>                       e.lk                     To:
>> axis-c-dev@ws.apache.org
>>                                                cc:
>>                       08/11/04 05:40           Subject:  Re: SSL
>> implementation
>>                       Please respond to
>>                       "Apache AXIS C
>>                       Developers List"
>>
>>
>>
>>
>> Hi Fred,
>> In overall I agree with your design. But if we keep the same
>> Axis2Transport
>> class then we will have the problem of including ssl related stuff.  To
>> avoid that I create a ssl sub folder inside axis2 and put the derived
>> SecureChannel.* and Axis2SecureTransport.* there. This folder will be
>> reached in the build process only if ssl option is given in the
>> configureation. Below I'll explain this more
>>
>> I'll show the code snippets with a comment in each place where I make
>> changes. These comments will explain my move.
>>
>> in Call.cpp
>> ........
>> .......
>> all::Call (int bSecure) //I added a constructor with one argument. So in
>> the stub code where ssl support is needed
>> //They need to initialise Call object with this constructor.
>>
>> :m_pcEndPointUri(NULL), m_strProxyHost(""), m_uiProxyPort(0),
>> m_bUseProxy(false), m_bModuleInitialized(false)
>> {
>>     m_pAxisEngine = NULL;
>>     m_pIWSSZ = NULL;
>>     m_pIWSDZ = NULL;
>>     m_bSecure = bSecure;//new variable m_bSecure is intialized
>>     if (!g_bModuleInitialize)
>>     {
>>         initialize_module (0, m_bSecure); //Now initialize_module has
>> two
>> arguements. In the second arguement indicate
>>                                  //need for secure connection.
>>         m_bModuleInitialized = true;
>>     }
>>
>>     m_pTransport = NULL;
>>     m_nStatus = AXIS_SUCCESS;
>> }
>> ........
>> ........
>> In SOAPTransportFactory.cpp
>> ......
>> .....
>> int SOAPTransportFactory::initialize(int bSecure)//now it take one
>> argument.
>> {
>>         m_pcLibraryPath =
>> g_pConfig->getAxisConfProperty(AXCONF_TRANSPORTHTTP);
>>
>>         if (!loadLib())
>>         {
>>         if(bSecure)//If ssl is needed additional library exposed
>> function
>> is needed
>>                 m_SecureTrtCreate = (CREATE_OBJECT3)
>> PLATFORM_GETPROCADDR(m_LibHandler, CREATE_FUNCTION3);
>>         else
>>                 m_Create = (CREATE_OBJECT1)
>> PLATFORM_GETPROCADDR(m_LibHandler, CREATE_FUNCTION1);
>>         m_Delete = (DELETE_OBJECT1) PLATFORM_GETPROCADDR(m_LibHandler,
>> DELETE_FUNCTION1);
>>
>>         if (!m_SecureTrtCreate || !m_Create || !m_Delete)
>>         {
>>             unloadLib();
>>
>> ...
>> ...
>> OAPTransport*
>> SOAPTransportFactory::getTransportObject(AXIS_PROTOCOL_TYPE
>> eProtocol, int bSecure)//additional arguement bSecure
>> {
>>         SOAPTransport* pTpt;
>>         if(bSecure)
>>                 m_SecureTrtCreate(&pTpt);//If security needed create
>> this
>> transport library
>>         else
>>                 m_Create(&pTpt);
>>         return pTpt;
>> }
>> ...
>> ...
>> I create an subdirectory called ssl inside transport/axis2 folder
>> The Makefile.am for that folder looks like
>> ...
>> ...
>> lib_LTLIBRARIES = libaxis2_ssl_transport.la
>> AM_CPPFLAGS = $(CPPFLAGS)
>> libaxis2_ssl_transport_la_SOURCES = SecureChannel.cpp \
>>                                ../URL.cpp \
>>                                ../Axis2Transport.cpp \
>>                                ../Channel.cpp \
>>                                Axis2SecureTransport.cpp \
>>                                ../AxisTransportException.cpp
>>
>> libaxis2_ssl_transport_la_LIBADD = @SSLLIB@ -lstdc++
>> INCLUDES = -I../../../../include @SSLINC@
>> ...
>> ...
>> When axis c++ is built we need to give a new configure parameter if
>> need to ssl tranport library created as
>> ./configure --with-ssl=/usr/local/ssl/install
>>
>> According to this design if we don't need ssl tranport support then
>> We can buid the axis c++ without additional ssl libraries and includes
>> in our environment. Only if the user needs ssl support he need those
>> ssl related stuff in his environment and give the above additional
>> configure option. That was the problem with the earlier ssl transport
>> we had. There to built the tranport we need ssl in our environment.
>>
>> Now in addition to extra SecureChannel.cpp we need Axis2SecureTransport
>> class
>> derived from Axis2Transport
>> ...
>> ...
>> extern "C"
>> {
>> /* CreateSecureInstance() Is a C interface.
>>  */
>>     STORAGE_CLASS_INFO int CreateSecureInstance (SOAPTransport **
>> inst)//We need this additional
>>     //dll interface function to load ssl transport. We can't keep only
> one
>> Axis2SecureTransport
>>     //file because in it when we include ssl related includes then to
>> build the normal transport
>>     //we need to have ssl includes in our environment. That was the
>> problem with the my earlier
>>     //design and the design of Fred Preston.
>>     {
>>         *inst = new Axis2SecureTransport ();
>>         if (*inst)
>>         {
>>             return AXIS_SUCCESS;
>>         }
>>         return AXIS_FAIL;
>>     }
>> }
>> ...
>> ...
>> In this Axis2SecureTransport.cpp we need only setEndpintUri,
>> setTransportProperty
>> and getTransportProperty only(in addition to the above
>> CreateSecureInstance.)
>> Rest is in the Axis2Transport. I'm implementing this and note that it
>> just complements your work with some changes. I'm in the process of
>> testing it. But if you have different implementation let's discuss.
>>
>> thanks
>> damitha
>>
>>
>>
>>
>>
>
>
>
>
>


-- 
Damitha Kumarage
hSenid Software International (PVT) Ltd

Mime
View raw message