Great, so here is what I'm going to do:
- Rename 'JDK14JSSESocketFactory' back to 'JSSESocketFactory'. Strip out
sun specific code. Behaviour should be equivalent to
DefaultSecureSocketFactory, but code is cleaner. [The significant
difference between the two is that DefaultSecureSocketFactory (DSSF) uses
reflection & JSSESocketFactory does not. DSSF probably did that to allow
Axis runtime to load up without requiring 'javax.ssl.net.*' classes. Since
JSSESocketFactory is loaded dynamically, the same purpose is
accomplished.]
- Remove DefaultSecureSocketFactory.. JSSESocketFactory is more
descriptive.
- Leave Dim's 'original' code for Sun JDK in Sun*, and Doug's mods for the
IBM JDK in IBM* classes. If you want these (plus AXIS configurable
behavior), configure Axis for it (see integration guide - use system
property or services definition file).
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Davanum Srinivas <[EMAIL PROTECTED]>
10/10/2002 01:44 PM
Please respond to axis-dev
To: [EMAIL PROTECTED]
cc:
Subject: Re: JSSE Security - change direction...
Folks,
Sorry for the silence. Was at soapbuilders last 2 days and catching up on
work since this morning.
It all started with Costin wanting to hook in support for "untrusted
SSL certs" (See
http://marc.theaimsgroup.com/?l=axis-dev&m=101623382815671&w=2). You all
know where we stand
now...Am ok to drop support for TLS as default if that is the consensus.
All i wanted to do was
have one of these Impl's that can be configured at runtime....For example
i wanted to be able to
specify the keystore file name in my servlet's web.xml and switch between
SSL/TLS etc from another
config property in my web.xml.
Thanks,
dims
--- Richard Sitze <[EMAIL PROTECTED]> wrote:
> 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
>
>
>
>
>
=====
Davanum Srinivas - http://xml.apache.org/~dims/
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
