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 23:42:29 GMT
Harish Prabandham wrote:

> [snipped to include just the relevant responses]
> You might find it useful to abstract a concept of "realm" (also,
> called security domain) that has a set of users and groups. So,
> that you can extend it easily to support different types of users.

In a previous response, I outlined an approach whereby multiple web-apps could share
security domains (realms) if they wanted to, without having to represent the
security realm itself as an object.  We can of course make security domains first
class objects like contexts are, but it didn't seem necessary.

>       - Add lifecycle methods like start() and stop() that will be called
>         when the corresponding Context is started or stopped.
> This interceptor sounds interesting. If you do, it probably has to be
> tied to the ContextManager & would have some deployment implications.
> But, I cannot think of a scenario that does not involve deployment, where
> this would be useful.

The deployment issues can be mitigated if you pass the Context itself as an argument
to the start() method.  That way, the object being started can use the context's
initialization parameters to gracefully configure itself, and perform any expensive
one-time actions needed (such as establishing a JDBC or JNDI connection).  Likewise,
the stop() method gives the object a graceful way to release any resources allocated
in the start method in preparation for a shutdown -- or for the context being
replaced if & when Tomcat supports auto-reloading.

>       - Add a method to return the Principal being requested by a
>         particular request.  For example, if you are implementing
>         HTTP Basic authentication, you would extract the username and
>         password from the HTTP headers and return a corresponding
>         Principal, or null if there was no such principal (or the password
>         did not match).
> Are you considering support for HTTP Digest Authentication?

The servlet 2.2 spec requires us to support Basic and Digest (along with HTTPS-based
and form-based).  Each of these approaches uses different mechanisms to pass the
username and associated credentials.  Originally, I was trying to avoid creating a
method signature like this:

    Principal authenticate(String username, String credentials);

but maybe that is actually better.  The logic that goes in the interceptor has to
know about Basic vs. Digest vs. whatever, and which HTTP headers are used is
independent of the underlying security technology.  Likewise, the underlying
RequestSecurityProvider implementation doesn't care which approach you're using --
it only cares about being a database and authentication.

Thinking more as a result of this discussion, the approach described above might
work out better.

>   src/share/org/apache/tomcat/core/
>       - Update as necessary to conform to the interface changes
>         described above.
>   src/share/org/apache/tomcat/core/
>       - Provide properties to set and get a particular
>         RequestSecurityProvider
>         implementation (to be used by the configuration process).
>       - Initialize the security provider in the start() method, and
>         finalize it in the stop() method.
> Cool. This looks like an ideal place where providers should be
> started/stopped.
>       - Add additional properties required for operation of a functional
>         RequestSecurityProvider and SecurityInterceptor implementation.
>   src/share/org/apache/tomcat/core/ (NEW)
> tomcat.core is already a huge package. It would be nice to create
> another package.

I agree whole-heartedly.  If we were playing poker, "I will see your package and
raise you four more."  How about a new hierarchy like this:

        Contains interface definitions and shared classes
        related to authentication and access control (the
        RequestSecurityProvider interface would ultimately
        be moved here, for example).

        Would contain a RequestSecurityProvider implementation
        that went back through the Apache connector to utilize
        whatever security has been set up there.

        Would contain my proposed FileRequestSecurityProvider
        (we need to think about some shorter names) and
        associated stuff.  Maybe RequestSecurityProvider should
        even be renamed RealmConnector since that is what it's
        role is becoming?  This name would also work even if we
        later decided to make Realms first class objects.

        Implementation that accessed a database via JDBC.  The
        config parameters would define what JDBC data source to
        use, along with what table and column names to check.

        Implementation that accessed a directory server (or something)
        via JNDI.  The config parameters would define the connection
        properties for JNDI, plus some generalized mechanism to specify
        the JNDI search filters needed to answer the needed questions.

If we do this, we can check in and evaluate new concepts with no risk to the
existing code base, until we're ready to go back and retrofit.  Does that make


View raw message