axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa_abeysin...@yahoo.com>
Subject Re: SSL implementation
Date Thu, 04 Nov 2004 10:54:50 GMT
Hi Fred,
    Thank you for your prompt reply. Your answers cleared many confusions that had.
    One of the key things is that, I was under the impression that you were trying to insert
a lib
specific implementation into the transport. I now understand that your effort was to define
a
template.

    Re: DLL type solution where you can identify in the config file your
secure channel implementation ->
   
    +1. I think this is the ideal solution to eliminate the unwanted dependancies on external
SSL
libs.

Thanks,
Samisa...

--- Fred Preston <PRESTONF@uk.ibm.com> wrote:

> 
> 
> 
> 
> Hi Samisa,
>       I have replied to your comments in bold...  Thank you for the full
> and detailed questions, your response is very useful.  I hope my replies
> are satisfactory and I look forward to your responses.
> 
> Best regards,
> 
> Fred Preston.
> 
> 
> 
>                                                                                     
           
>                                        
>                       Samisa Abeysinghe                                             
           
>                                        
>                       <samisa_abeysinghe        To:       Apache AXIS C Developers
List
> <axis-c-dev@ws.apache.org>                      
>                       @yahoo.com>               cc:                              
              
>                                        
>                                                 Subject:  Re: SSL implementation    
           
>                                        
>                       04/11/04 02:36                                                
           
>                                        
>                       Please respond to                                             
           
>                                        
>                       "Apache AXIS C                                                
           
>                                        
>                       Developers List"                                              
           
>                                        
>                                                                                     
           
>                                        
> 
> 
> 
> Hi Fred,
>     I have few more thoughts in addtion to the 5 points in earlier email.
> 6. What are the possible attributes set through setSecurity() method?
> > A: These can be any strings that you need for secure channel
> initialisation.  They could
> >    be SSL cipher options, locations of keyring databases, etc.
> >
> 7. Is it reasonable if we enforce that, if one wants to use SSL with
> client, he/she must change
> axiscpp.conf file and set Transport_http to a lib having SSL support. If
> this is acceptable, then
> if we could get rid of setSecurity() method mentioned in 6 above, we can
> make SSL transparent to
> user. What do you think?
> > A: Good idea.  I hadn't though of that.  I will have to think of the
> security issues, but it
> >    sounds like a good idea.
> Your design is an eye opener for us to see what we have missed when
> transport abstraction layer
> was designed. Thank you for your efforts on this Secure Channel design.
> 
> Regards,
> Samisa...
> 
> --- Samisa Abeysinghe <samisa_abeysinghe@yahoo.com> wrote:
> 
> > Hi Fred,
> >     Fre question.
> > 1. Why do you need setServerName() in ISecureChannel class? Can't you use
> the URL class (Which
> > is contained in Channel class) for this?
> > A: These are my solutions to implementation problems and when I cut 'n
> pasted from my SSL
> >    implementation they got left in by mistake.  This also applied to
> getServerName method and
> >    the protected variable sServerName in the header file.
> >
> > 2. Why do you have openConnection() and OpenSecureSocket() [and
> closeConnection()/
> > CloseSecuritySocket()] in SecureChannel class? Why this pair? Why not
> one? I think you do not
> > need
> > any of them and could override open() and close() inherited from Channel
> straightaway. I think
> > the
> > same applies to >> and << operations (simply override and no need for
> write/readSecureSocket
> > methods).
> > A: Yes, I originally left these in to show some detail.  In fact these
> and all of the private
> >    methods must be removed from the template.
> >
> > 3. This design requires changes to Axis2Transport class to select between
> secure vs. non-secure
> > channel. That means users have to have at least one concrete
> implementation of the secure channel
> > to use Axis C++. Now the question is different users need different
> underlying libs, and we are
> > going make at least one SSL lib mandatory to use Axis C++. I think a
> better option would be to
> > have this security enabled transport as a separate lib in a separate
> folder, say axis2secure, and
> > inherit from Axis2Transport and do whatever changes necessary. This way,
> those who do not need
> > security would not have to have an SSL lib on their system.
> > A: I started off with this approach, but because so much of the new code
> was very similar, but
> >    different, it was looking like we would have to maintain two copies of
> what is basically the
> >    same transport code.  As the secure channel code is only a template at
> this time, relying on
> >    no other libraries and will only be created if you use a URL that
> starts with https the
> >    inclusion of this template is benign. I think the important thing at
> this stage is to agree
> >    on an API that will support any third party SSL.  Saying all this, I
> am now leaning towards a
> >    DLL type solution where you can identify in the config file your
> secure channel implementation.
> >
> > 4. I am looking into implementing Keep-Alive support to axis2 transport.
> This means I will be
> > changing the how the connection is managed by Channel class (when to
> close, when to re-open
> > etc.)  How can we make the SecureChannel class to capture those changes?.
> > A: My implementation of SecureChannel creates a Channel object and calls
> Channel methods for
> >    open, read, write and close, so any changes in Channel will be
> automatically be picked up.
> >    For example, on open, I initialise the SSL library, call Channel->open
> and then pass the
> >    socket to the SSL library.
> >
> > 5. This morning when I got a fresh CVS checkout and compiled I ran into
> compilation errors:
> >  g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include -Wall -Wshadow
> -DENABLE_AXISTRACE
> > -Wall
> > -Wshadow -DENABLE_AXISTRACE -g -O2 -MT SecureChannel.lo -MD -MP -MF
> .deps/SecureChannel.Tpo -c
> > SecureChannel.cpp  -fPIC -DPIC -o .libs/SecureChannel.o
> > In file included from SecureChannel.cpp:1:
> > SecureChannel.h:12: error: looser throw specifier for `virtual bool
> >    SecureChannel::open() throw (AxisTransportException)'
> > Channel.h:92: error:   overriding `virtual bool Channel::open() throw
> >    (AxisTransportException&)'
> > SecureChannel.h:12: error: looser throw specifier for `virtual bool
> >    SecureChannel::open() throw (AxisTransportException)'
> > Channel.h:92: error:   overriding `virtual bool Channel::open() throw
> >    (AxisTransportException&)'
> > SecureChannel.cpp: In member function `virtual void
> >    SecureChannel::setSecureProperties(const char*)':
> > SecureChannel.cpp:70: warning: unused variable `std::string*ps'
> > make[4]: *** [SecureChannel.lo] Error 1
> > A: I have tried to make the code more explicit by adding 'throws
> (Exception)' to those methods
> >    that may throw an exception.  This is optional, but I have found it
> useful when trying to track
> >    down what methods throw what exceptions.  Unfortunately if you do it
> in the .cpp file but miss
> >    it out in the .hpp file it will break the build, but only on Linux and
> last night I only had
> >    time to test it on Windows.  I will fix this problem now.
> 
> > Thanks,
> > Samisa...
> >
> >
> > --- Fred Preston <PRESTONF@uk.ibm.com> wrote:
> >
> > >
> > >
> > >
> > >
> > > Hi All,
> > >       I'm currently implementing an SSL solution, but  want to make
> sure
> > > that I've covered all the bases before I commit it to CVS.  Here is my
> > > proposal...
> > >
> > > (See attached file: Adding SSL to Transport.doc)
> > >
> > > Does anyone have any views on my implementation (API, etc) before I
> commit
> > > these changes to CVS.
> > >
> > > Regards,
> > >
> > > Fred Preston.
> >
> > > ATTACHMENT part 2 application/msword name=Adding SSL to Transport.doc
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Check out the new Yahoo! Front Page.
> > www.yahoo.com
> >
> >
> >
> 
=== message truncated ===



		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 


Mime
View raw message