Larry Isaacs wrote:
>
> Hi Christopher,
>
> I would be very interested in having this available for Tomcat 3.3.
> Since I'm not a security expert, I'll defer to those better informed
> to decide the appropriate solution. Would this "keystore security
> solution" plug into Tomcat 3.3 using an interceptor? If there are
> changes needed in the core classes to support this, I would be in
> favor of including these changes in 3.3.
Hi Larry!
Based on the initial question raised by Craig, and some great ideas from
Jim, what seems to be taking shape is a two-stage solution.
The first part will be relatively simple. There will be some kind of
configuration option, presumably in server.xml, which will allow you to
specify that you should be prompted for the keystore password on startup
(rather than having it specified as a Connector "keystorePass"
attribute). My current thinking is simply to modify the server.xml
parsing code to prompt for the password if it is not specified in the
Connector tag. That approach would require no real additions/changes to
the server.xml structure. It simply allows a user to type in their
password manually at startup if they are not comfortable (as I am not)
storing it in the config file. That approach has the benefit of being
simple and intutive from the user point of view, and also pretty
low-impact on the existing TC code. Plus it leaves the default as-is:
Since everyone running Standalone+SSL already has the keystorePass
specified, the change wouldn't affect any existing installs (but would
be exceedingly easy to implement ... just remove the keystorePass
attribute :-). This piece would probably only require a mod to the
server.xml parsing code.
The second stage, which will require alot more discussion and
significant initial design, is the more comprehensive "External Resource
Security" module. That is the piece that I would like to see in commons
(or wherever), as I would want it to be a pluggable module if possible.
The idea here would be to centralize control of all the external (to
Tomcat) security pieces. If I read Craig's initial hesitation on the SSL
patch correctly, it was that he didn't want to start seeing a bunch of
disseparate approaches for locking down every external resource that
Tomcat can access (JDBC Realms, LDAP, etc.). That's an understandable
concern, so this stage would address the entire issue from a single
module. In my mind, this doesn't obviate the need for the "prompt me"
option at startup, and in fact is quite complimentary. If you want to
control access to all external resources from a single point, it's a
good idea to implement a pretty good authentication step. Since some of
these resources (such as SSL) need to be "initialized" at startup,
authentication at that stage pretty much boils down to command-line
prompt. Of course all of this is configurable, so that people whose
security needs are not that stringent are not bothered with such things.
All of this is my vision, anyway. Comments/flames are more than welcome
:-)
Of course, I have gotten buy-in from exactly zero committers at this
point (other than you :-), so this is all wildly speculative. I really
can't see the harm in letting me put together the something on at least
the first step, since it is a) existing-install friendly, b) covers the
most potentially risky problem, and c) would have a pretty minimal
impact on the existing codebase and require not alot of code. Stage two
is a little bigger endeavor, but we can cross that bridge when we come
to it. It was simply a good suggestion (Jim's, actually) for addressing
Craig's broader concern going forward.
> Since this solution will be used by Tomcat 4.0 as well, jakarta-tomcat
> may not be the best place for the source, other than changes to the 3.3
> core (assuming it can plug in as an interceptor). Outside of
> jakarta-tomcat it could have it's own release schedule and be developed
> to support both Tomcat 3.3 and 4.0. I'm not knowledgeable about what is
> in jakarta-commons to say if that would be a good place, or whether
> we need a new project, perhaps jakarta-tomcat-plugins or
> jakarta-tomcat-addons, to hold something like this.
I agree. In my opinion, the codebase for the second part should live in
some kind of "module" repository. All of your suggestions sound pretty
reasonable to me, and honestly I'll leave that up to you committers. But
again, the only permission I am looking for at the moment is simply to
do step one. Once that is in place, my personal itch is scratched. I do
think the larger proposal makes sense and would love to drive, but I see
that as a little more in the future.
Regards,
Christopher
