tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [VOTE] Short Term Plan: Add Security Management Capabilities to Tomc
Date Sat, 16 Oct 1999 18:41:06 GMT wrote:

> +1  on adding authentication and authorization support in Tomcat

[snipping the relatively long message to comment on a few particular points]

> In a "production" environment, Tomcat is supposed to work in conjunction
> with Apache - and they need to share the same authentication/authorization
> rules and policy.

This (connected to Apache) is *one* of the production environments that will
be present, but by no means the only one.  We'll see connectors to other
servers as well.  In fact, I plan to run my 100% dynamic web apps on Tomcat
standalone once the HTTP support is improved a little.  I want to take
advantage of container-managed security, and I can't without this enhancement.

> While support for security in standalone mode is important for developers,
> to test and develop - the design must be focused on the "production" case,
> and the requirements and implementation should reflect that.

One person's development environment is another person's production
environment.  Of course, a good pluggable architecture should make it easy to
have implementations that perform well in any environment.

> With any bidirectional connector it is possible to do callbacks - that will
> be one particular SecurityProvider.

Where is the connector stuff checked in?  To do this, we'll need to make sure
that the security provider working on a particular reqeust can get back to the
connector that request came through (so that it can go back and ask Apache the
appropriate questions, in this particular case).  I need to take a look at
what's there to ensure that this is easy.

Apache's concept of a "user" pretty much matches what the servlet API
requirements need, but Apache itself does not have the explicit concept of a
"role" in it's security model.  What would you think of using Apache's "group"
idea to play the role of a "role" (pun intended :-)?

> >     - Add additional properties required for operation of a functional
> >       RequestSecurityProvider and SecurityInterceptor implementation.
> No changes are required in Context - the security provider can be managed
> outside a Context ( configuration/management code will control both Context
> and Security providers  ). That will allow more flexibility ( a context may
> have multiple Security providers, including Auth Providers, Access
> providers, and you'll be able to restart security providers independent of
> Context ( when you add a new user, no need to restart the context)

It turns out that Context already knows about the security provider it is
using -- see the "rsProvider" instance variable, and the corresponding "get"
and "set" methods.  Somehow, I missed this in my initial review.  All we need
to do there is make sure the "set" method is called correctly when the context
is configured.

Having more than one security provider active at the same time, for the same
context, does not really make sense to me.  If you do this, which one do you
ask first?  What do you do if security provider #1 says that "costin" is
manager, but provider #2 doesn't?  You could possibly make a case for having
separate providers for authentication and access control, but all the legacy
implementations of this that I've ever seen (including the ones I have custom
built in my own applications) always combine these two things.

Restarting the context to recognize new users would be needed for the simple
FileRequestSecurityProvider that I've proposed, but isn't necessary for ones
that go back to Apache, or use databases or directory servers.  Any of those
providers would do a dynamic lookup into the underlying data store whenever
they are asked.

> > src/share/org/apache/tomcat/shell/deployment/server.dtd
> >
> >     - Add a new "requestSecurityManager" attribute to the <Context>
> >       element, that identifies the Java class name of the
> >       RequestSecurityManager to be utilized.  Default is the
> >       existing DefaultRequestSecurityManager stub.
> RequestSecurityManager doesn't have to be sub-ordinate of Context, but a
> stand-alone module. ( it will have it's own configuration requirements -
> like DB name, driver, etc).

It does if you want to use different RSM implementations (or the same
implementation with different initialization arguments) for different web
applications in the same servlet container.

You will note that I did not suggest adding initialization parameters (so a
JDBC-based RSM implementation could find its appropriate data source and so
on).  The thinking was that you'd pass the Context reference to the start()
method of the RSM instance, thus giving it access to the context's
initialization parameters.

You can use the same underlying RSM implementation for more than one context,
just like you can register the same servlet more than once (under a different
name and mapping) inside a context.  You'll get a separate instance of the RSM
class for each.  In the Apache connector case, they would all point back to
the underlying Connector, but would be able to pass the arguments that are
different per context for Apache's use in answering the question correctly.

> We need a generic way to add interceptors to a Context,  and an Interceptor
> will have a reference to a RSM. ( see apache auth model )

I agree that a general model will be useful.  As James pointed out in a
separate message, interceptors will also be used for other things like
transaction control.  The interceptors would seem to need start() and stop()
type lifecycle capabilities themselves, along with a standard way to configure

Right now, the LifecycleInterceptor interface seems a little weak for this,
but I need to understand how the J2EE implentation is able to use it at all
before I recommend any changes.

> Costin
> P.S.
> Craig, I was missing your mails :-)

Ah yes, we're back to the good old days... I missed it too :-).  Glad to see
that you're involved with this; the Apache connector stuff sounds pretty

> It would be great if we can have this done on "short term" ( and right)...

With Apache JServ we got to start from a clean slate and build a nice
component based architecture.  This one's going to take a little longer, but
we'll get there ...


View raw message