Hi Christopher,
I just checked, and for 3.3 you don't need any change in the core or any
other place in tomcat.
All you need to do is write a simple interceptor and implement
addInterceptor() callback.
In the implementation all you have to do is ask for a password ( one
sugestion: you can add an option and before asking for pass you can do a
url connection to a "key server" ? ).
You will also need to call getModules(), look for Http10Interceptor and
call setKeypass().
In the config file you'll just add your module ( after Http10Interceptor -
it can be in any position, but the code will be a bit more complex ).
I'm -1 on checking this into tomcat CVS, +1 on checking it into a
"modules" repository or placing it anywhere outside tomcat. The reasons:
first we're in beta, that means only bug fixes. But the important one -
this is not an "essential" feature, I think it's very important to keep
the basic distribution focused on what's essential and without featurism.
( I agree there are many modules in the current 3.3 distribution that are
also not essential and shouldn't be there, but it's hard to remove
existing code, even if that would be benefical ).
Please don't let this affect your work - I'm -1 on adding any feature that
is not required by the spec as long as it can be implemented as a module,
including my own "itches".
If you find you need any additional callback or API in the core or
existing modules - please let us know ASAP, that would be a flaw that must
be fixed before we release.
Costin
> 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
>
