Doug,
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
DefaultSecureSocketFactory.
As long as we require TLS, we have no recourse other than com.sun.* and
(alternately) com.ibm.*.
<ras>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Doug Davis/Raleigh/IBM@IBMUS
10/10/2002 05:52 AM
Please respond to axis-dev
To: [EMAIL PROTECTED]
cc:
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
a
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
or
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.
-Dug
Richard Sitze/Austin/IBM@IBMUS on 10/09/2002 02:25:35 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: JSSE Security - change direction...
I'd appreciate Dim's opinions on this:
Problem:
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
http://java.sun.com/products/jsse/doc/guide/API_users_guide.html#InstallationAndCustomization
).
** 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.*.
Proposal:
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.
Justification:
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.
Concerns:
Change of current behaviour
Out-of-box experience...
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
