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 Wed, 19 Apr 2000 23:25:46 GMT
"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.


> Craig
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Assaf Arkin                                 
CTO, Exoffice Technologies, Inc.              

View raw message