tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: authorization providers (was More on JAAS)
Date Wed, 19 Apr 2000 23:54:10 GMT
Arkin wrote:

> "Craig R. McClanahan" wrote:
> > In the case of Catalina's "Realm" interface, the only Tomcat dependency is on
> > the Container interface.  The rationale is this:  "Realm is an interface that a
> > security domain must implement to allow Tomcat to authenticate users and
> > validate roles."  Given that this is the whole point of Realm, it does not seem
> > like a problem to me -- plus, it allows the security domain to access other
> > resources of the container if needed.
>
> Which means a security provider has to be developed for Tomcat
> specifically and cannot be used for any other container.
>
> > Beyond that, it's not clear whether we can get away with just the current
> > authenticate() methods, or whether we might also (or instead) need:
> >
> >     public boolean authenticate(Request request);
> >
> > because we want to allow a realm implementation to access any request
> > properties it needs to.  This introduces one more dependency on the Tomcat
> > internals, but it's still a Tomcat internal API -- that's OK with me.
>
> In my opinion an authentication interceptor (Tomcat specific) should be
> used for that, not a generic security provider. A generic security
> provide has no notion of HTTP. In fact, it may be called at any point
> without any relation to an HTTP request.

> > Note:  a Realm implementation that itself uses JAAS (on a 1.3 platform)
> > certainly makes a lot of sense.  But it is not sufficient for many other cases
> > -- for example, a J2EE server with Tomcat embedded in it will have it's own
> > notion of users and roles for use by the EJB side, and you want the servlet
> > side to attach itself to that existing implementation.
>
> Actually the Servlet container would server as the point of
> authentication/authorization, create the Subject and let the EJB and
> connector rely on that. The principal and roles are identical for Web
> and EJB container.
>

There are (at least) two pieces to the puzzle:

* How does a servlet container implement HTTP
  BASIC (or DIGEST or whatever) authentication
  at the protocol level (i.e. sending the right HTTP
  headers and interpreting the responses).

* How does the servlet container know whether
  the credentials presented by a particular user
  are valid, and (by the way) what "roles" the now
  authenticated user possesses.

The two issues are independent, and should be addressed independently:

* The mechanics of doing something like the
  BASIC authentication protocol are generic,
  no matter how you validate users.  It is appropriate
  to implement this as a request interceptor (SecurityCheck
  in Tomcat 3.x, SecurityValve in Catalina).

* The way that you validate a user is fairly generic,
  no matter which authentication method (BASIC,
  DIGEST, FORM) you choose for your web app.
  It's not quite as clear cut because of things like
 SSL, where you are tapping into a somewhat
  different processing model.

So, what you'd like is a generic way for the request interceptor (or Valve) to say
"here is a username and a password -- is it a valid combination?"  Thus, you need to
define an internal-to-your-request-interceptor API by which that question is asked.
As you point out, you don't want the security domain that answers the question to
know anything about HTTP.  At the same time, you don't want your BASIC authentication
implementation to care abou the differences between looking up users in a database,
or a directory server, or whatever.  Thus, in design patterns terms, you want an
"adapter" in between.  That's what a Realm interface really facilitates - the
implementation adapts the BASIC authentication interceptor's view of the world (very
HTTP-centric) to the security domain's view of the world (lots of variations in
implementation).

The challenge, of course, is how do we standardize how much information from the
incoming HTTP request is needed to perform the authentication.  Username and password
(or username and a byte array of credentials) cover the simple cases -- it's not
clear that they cover all of them.

Given that the customer of the Realm interface is in fact a Tomcat component (the
authorization interceptor), it doesn't bother me that the Realm interface is Tomcat
specific.  This does not at all imply that a Realm implementation must actually do
all the work (although that's possible) -- in most cases it will simply delegate to
some existing security domain implementation that really does the work.  For example,
if you were integrating Tomcat inside a J2EE server, you'd simply adapt to the
security domain stuff that already exists within that server, rather than
re-inventing it from scracth.

How the delegation actually happens is a private decision of the Realm implementor,
totally invisible to Tomcat's core servlet container.  Likewise, how Tomcat uses the
answers to authentication questions (for example, send an HTTP "Not authorized"
response) is invisible to the Realm implementation, and also therefore invisible to
the underlying security domain.

>
> arkin
>

Craig



Mime
View raw message