tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: How do I know what security manager is in use?
Date Tue, 02 Oct 2001 17:04:02 GMT

On Tue, 2 Oct 2001, Frank Lawlor wrote:

> Date: Tue, 2 Oct 2001 11:29:41 -0500
> From: Frank Lawlor <>
> Reply-To:,
> To: "Tomcat (E-mail)" <>
> Subject: How do I know what security manager is in use?
> There are now (at least) 3 different web security managers which could
> be in use by a web app (JDBC, JNDI, in-memory).  How can I tell which one?

It sounds like you're really asking which *Realm* is in use, right?
SecurityManager is something different from this.

>From code inside Tomcat, the way to find out which one is in use would be
to get a reference to the current Context, and then call the getRealm()
method.  Then, you could (for example) do an "instanceof" test to see
which implementation is in use.

In order to get a reference to the Context from a servlet, your servlet
class must implement the ContainerServlet interface, and be installed
inside Catalina (in the server/classes or server/lib directory), because
normal servlets are not allowed to access

> I am writing some general support classes to manage users and
> roles.  To support a call like addUser() I need to know which
> security manager is in use so I can do the right thing.
> Doing things like checking for tomcat-usrs.xml or a particular
> security class don't seem adequate.

You should not be using MemoryRealm for a production application.

A completely separate approach would be to write a regular webapp that
talks directly to the underlying database (or directory server) containing
your authentication data.  Any new user that you add, for example, is
immediately recognized -- there is no real reason to mess around with the
internal Realm implementation class at all.

> Further, if the class is, say, JDBCRealm, I would like to also
> get the xml properties for connectionURL, connectionName,
> connectionPassword, etc. or maybe even the connection
> itself.

Check out the implementation classes, and you'll see that much of this
stuff is visible as JavaBeans properties.  If you do the "container
servlet" approach, you can call any public method of these classes.  But,
I suggest that you don't go this way - it adds needless complexity and
ties you incredibly tightly to Tomcat's internal architecture.

> It seems like this is something the servlet spec should address.

In the JSR-053 discussion group that came up with Servlet 2.3, we did some
initial discussion of this.  But it's a much bigger topic than just
servlets (because EJBs use the same security model) - it's likely to end
up with a new JSR that covers these sorts of issues.

> Any suggestions?
> Frank Lawlor
> Athens Group, Inc.
> (512) 345-0600 x151
> Athens Group, an employee-owned consulting firm integrating technology
> strategy and software solutions.

Craig McClanahan

View raw message