axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: JSSE Security - change direction...
Date Thu, 10 Oct 2002 18:05:02 GMT

it appears that the most significant differences are:

1.  The JSSE code uses Transport Layer Security (TLS) instead of Secure 
Sockets Layer (SSL).  Can't say *why* this is significant or desirable as 
a default...

2.  Default use of   System.getProperty("user.home") + "/.keystore"  for 
the keystore file.

If I rip that out, I essentially end up with a (cleaner) version of 
JSSESocketFactory that matches the behaviour of 

As long as we require TLS, we have no recourse other than com.sun.* and 


Richard A. Sitze
IBM WebSphere WebServices Development

Doug Davis/Raleigh/IBM@IBMUS
10/10/2002 05:52 AM
Please respond to axis-dev
        Subject:        Re: JSSE Security - change direction...


Richard (or perhaps its Dims),
  Can I ask you to do me a favor and really dumb down this discussion for 
moment because I'm still not clear on the entire need for this
"architecture" - it feels like its a solution looking for a problem. Let's
start with a very basic question - looking at Beta3, what wasn't working 
supported that this new architecture now fixes/supports?  I'm not talking
about looking at it from an axis-dev'ers point of view but from an
end-user's.  Back in Beta3, when everything was in HTTPSender,  "http" and
"https" both worked with any implementation without any code or property
file changes - so why the redesign?  Perhaps this is a question for Dims -
don't know - but I'd really like to get a clear answer on what the problem
was before we start redesigning a solution that might not have even been
needed in the first place.

Richard Sitze/Austin/IBM@IBMUS on 10/09/2002 02:25:35 PM

Please respond to

Subject:    JSSE Security - change direction...

I'd appreciate Dim's opinions on this:

     JSSE is/was bound to sun implementation, in code.
     JSSE can be configured by code (considered 'dynamic'), or configured
during install/registration ('static') with the JDK (see

     ** the use of the terms dynamic/static in this context may be
misleading if you don't take the time to grok it  **
     Current code uses dynamic (in-line code), introducing a hard
dependency on com.sun.*.

     Remove hard dependencies, replace with static binding (configure your
JDK externally, NOT by AXIS).
     Eliminate 'attribute' overrides with default values.  Could go ahead
with override (maybe), but the default should fall-back to JDK settings,
NOT axis defined defaults.
     If attribute overrides are not specified, then fall back to JDK
default.  Currently we only use JDK default if attributes==null.

     AXIS should not be defining or changing the security providers.
     Basis of concern is that AXIS should run WITHIN an environment, NOT
define the environment
     Particularly with J2EE in mind.

     Change of current behaviour
     Out-of-box experience...

Richard A. Sitze
IBM WebSphere WebServices Development

View raw message