tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arkin <>
Subject Re: authorization providers (was More on JAAS)
Date Thu, 20 Apr 2000 00:10:59 GMT
It's hard for me to comment on this e-mail, it seems to confuse two
different topics. One is authentication at the protocol level (HTTP,
WAP, etc) and one is back end authentication and authorization.

The first is totally dependent on the protocol. It might work different
for HTTP than for WAP, it might work different if Tomcat is standalone
vs. connected to Apache. It might work different for HTTP 1.0 than 1.1.

The second is totally dependent on the container API defined in the J2EE
architecture and covers the authentication & authorization of users,
regardless of protocol. It works the same way whether the protocol is
HTTP or WAP, RMI or IIOP, client application or server, synchronous or
asynchronous (JMS).

In my opinion it's Tomcat's responsibility to support at the least an
HTTP adapter and delegate that to a security provider, but the security
provider need not understand HTTP specific issues, or even be exposed to
such issues.


"Craig R. McClanahan" wrote:
> Arkin wrote:
> > "Craig R. McClanahan" wrote:
> > > In the case of Catalina's "Realm" interface, the only Tomcat dependency is
> > > the Container interface.  The rationale is this:  "Realm is an interface that
> > > 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
> > > 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Assaf Arkin                                 
CTO, Exoffice Technologies, Inc.              

View raw message