tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject [VOTE] Short Term Plan: Add Security Management Capabilities to Tomc
Date Sat, 16 Oct 1999 06:16:21 GMT
(PMC Members:  You've seen this already; please comment and vote here so
the responses are visible to all)

(Everyone:  This is a proposal to make a substantitive, non-bug-fix,
change to the Tomcat code.  Per the Decision Making page on the Jakarta
web site -- --
everyone is encouraged to comment on and suggest improvements in the
proposal, but the votes of Committers are binding.)


The servlet API version 2.2 enhancements include some very nice
mechanisms for applications to depend on container managed
authentication and access control capabilities.  The J2EE reference
implementation, and most commercial J2EE implementations, will support
this functionality in their application servers.  Unfortunately, at the
moment, Tomcat as a development environment does not support this.  The
purpose of this short term plan activity is to provide support for a
pluggable security management component that lets developers design an
authentication and/or access control model, and perform development
using only Tomcat as their development environment, but still depend on
container managed security.

The existing Tomcat code has only the bare rudiments of support for
security, in the form of the RequestSecurityProvider interface, and the
DefaultRequestSecurityProvider implementation.  This action will result
in the following enhancements:

* Fleshing out the request security provider interface
  with additional methods required for production implementation.

* Creation of functionality, which will utilize the "Interceptor"
  technology that wraps calls to the service() method of servlets,
  to enforce the authentication and access control mechanisms
  described in the Servlet API Version 2.2 specification.

* Implementation of at least one security provider that interacts
  with text configuration files in a manner similar to the way that
  Apache's security manager uses password and group files.
  Additional security providers that interact with JDBC-based
  databases, and JNDI-accessed directory servers, can be added


Based on my analysis so far, the following work items seem to be


    NOTE:  Changes to this interface require coordination with the J2EE
    reference implementation team before they are committed.
    Alternative spproaches will be considered if necessary to meet their

    - Add lifecycle methods like start() and stop() that will be called
      when the corresponding Context is started or stopped.

    - 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).


    - Update as necessary to conform to the interface changes
      described above.


    - Provide properties to set and get a particular
      implementation (to be used by the configuration process).

    - Initialize the security provider in the start() method, and
      finalize it in the stop() method.

    - Add additional properties required for operation of a functional
      RequestSecurityProvider and SecurityInterceptor implementation.

src/share/org/apache/tomcat/core/ (NEW)

    - Simple implementation of the RequestSecurityProvider
      interface that utilizes text-based configuration files (perhaps
      in XML, since we need an XML parser anyway) to define
      users, passwords, and the roles they can play.

src/share/org/apache/tomcat/core/ (NEW)

    - Interceptor implementation to enforce the authentication
      and access control requirements of the Servlet API 2.2 spec.

    - Contains common security functionality that is independent
      of the particular mechanism used to store users and roles
      (i.e. those provided by RequestSecurityManager implementations).

    - NOTE:  It is not clear how the J2EE reference implementation
      can perform all of the required authentication and access control
      checks, given the existing Interceptor functionality.  Of course,
      that's probably me not knowing the code well enough yet.  Further
      discussions with the J2EE reference implementation team may
      generate modifications to this design pattern.


    - 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.


    - Initialize the Context property that identifies the Java class
      name of the RequestSecurityProvider implementation class to use.


    - Add property to capture the Java class name of the
      RequestSecurityProvider implementation class to use.

View raw message