tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Authentication hook?
Date Fri, 07 Apr 2000 15:43:00 GMT wrote:

> Just some thought about authentication in case some of the developers are
> listening:
> It would be nice to have a general web server based authentication mechanism
> with possibility to hook in a special made authentication mechanism. I may
> not be explaining this very well so I will try to give an example:
> In the project I am working in now we have made a portal for a low end
> terminal. We do not want the user to authenticate each time the user
> accesses the portal. We could use long lived cookies for this purpose but
> the terminal can not handle many cookies so this cookie might be pushed out
> at some time. So we need to make another terminal spesific authentication
> mechanism. We also do not want to have this on each JSP page so a general
> authentication mechanism which works for all the pages of a web application
> would be nice. We also need to be able to hook our own special
> authentication mechanism to this general mechanism.

There are two levels at which a servlet container can help you with
authentication, as described in the servlet 2.2 spec:

* At the per-web-application level.  You declare your security constraints
  in the web.xml file, in terms like "only people who are authenticated to
  role xyz can have access to this set of URLs".  See below for my thoughts
  on generalizing the "authenticated" part of this.

* At the per-container level.  The spec talks (Section 11.6) about containers
  managing authentication information at the per-container level, so you can
  sign on once for all the apps hosted within this container.  This sounds to me

  like what you need for your portal requirement -- is that right?

Tomcat currently allows you to use HTTP BASIC authentication for the first
scenario above.  It doesn't yet have any support for the second.

However, the Tomcat code also combines two concepts into one class in the
current implementation that should really be split:

- How do I execute the mechanics of the authentication
  dialog with the user (for example, with BASIC authentication
  you send back the "UNAUTHORIZED" status that makes your
  browser pop up the username/password dialog box.

- How do I validate that a particular username/password combination
  is acceptable, and what roles that user is authorized for?

The first concept is generic, and should be created that way.  The second
concept is the place where you should be able to plug in your own
implementation, so that you can attach to an LDAP server, attach to a PAM
implementation, read an Apache username or group file, or whatever else you want
to do.  Right now, Tomcat combines these into one class
(org.apache.tomcat.request.SecurityCheck).  I would like to see this split so
that you can plug in your own implementation of the lookup stuff, without having
to mess with the interaction dialog.

As an example of how to do this, the "Catalina" proposal for Tomcat's future
(see the proposals/catalina subdirectory in the Tomcat source code distribution)
explicitly separates these issues by virtue of the Realm interface.  It has
methods like this:
    public interface Realm {
        public Principal authenticate(String username, String credentials);
        public boolean hasRole(Principal princpal, String role);
so that you can conveniently separate the lookup stuff out.  All you do is
implement the code to answer these questions in your favorite "database" of
users/passwords/roles, and you are done.

> By the way should this mail have been sent to one of the other mail lists or
> somewhere else?

TOMCAT-USER is fine for expressing desires.  However, the actual discussions
about what features go into Tomcat, how they will work, and when they will be
worked on take place on the TOMCAT-DEV list.  Of course, if you'd like to help
us make this work by contributing code, we'd like that too :-).

> Best regards
> Arne C. HÃ¥rseth

Craig McClanahan

View raw message