tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: authorization providers (was More on JAAS)
Date Thu, 20 Apr 2000 00:30:40 GMT
> > * 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).

Or in a BasicAuthenticate class? And FormAuthenticate to
deal with form based authentication ?

And the interceptor just uses the components implementing certain
forms of authentication and the security APIs.

Again: interceptors are not supposed to _implement_ a certain
authentication protocol, but to act as a _bridge_ between various
APIs. SecurityCheck is just one example on how authentication
can be done, and does have everything in it's body just to allow
easy development and allow people to understand the code.
Even in SecurityCheck - most of the code for Form authentication
is moved in a normal servlet, and probably any other form of authentication
can and should be moved.

After all, it is perfectly valid to not declare any authentication method
in web.xml and have the servlet implement it in "user space". That have
quite a few valid use-cases - for example an ISP may host a web
application but will not want to handle users-management.
There is no restriction in the spec that "the only way to use BASIC
authentication is via web.xml ". Having normal "components" for
authentication and only putting them togheter in the interceptor is a
much better design ( IMHO )


> >
> > * 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
> > 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
> > all the work (although that's possible) -- in most cases it will simply delegate
> > 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
> > answers to authentication questions (for example, send an HTTP "Not authorized"
> > response) is invisible to the Realm implementation, and also therefore invisible
> > the underlying security domain.
> >
> > >
> > > arkin
> > >
> >
> > Craig
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> --
> ----------------------------------------------------------------------
> Assaf Arkin                                 
> CTO, Exoffice Technologies, Inc.              
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message