tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Eric Miller" <>
Subject Re: JNDIRealm questions
Date Thu, 23 Aug 2001 20:08:12 GMT
I did a search of the Tomcat Developer List archive and found that it looks
like #2 is possible (or was only planned and isn't yet implemented?), so,
that's cool. Now, if I could only find the documentation on how to use
this... ;-) Craig, if you're listening, can you post an example Realm entry
for JNDIRealm that would go in server.xml? If there were a JNDIRealm.howto,
like the JDBCRealm.howto, that would be great. I'm guessing that you guys
just haven't had a chance to do that yet. I'd being willing to write one up
similar to the JDBC one once I get it figured out. A sample entry for a user
and a role in LDIF format would also be very helpful. Also, I like the
example JDBCRealm entries that are currently in server.xml, if there was a
sample one for JNDIRealm that would be great.


[Tomcat 4] - JndiRealm Proposals

From: Craig R. McClanahan
Subject: [Tomcat 4] - JndiRealm Proposals
Date: Tue, 10 Apr 2001 10:05:39 -0700

Over the last few weeks, there has been a high degree of interest in
having a Realm implementation for Tomcat 4.0 that authorizes users via a
JNDI-accessed directory server (typically, but not limited to, LDAP
servers).  There have been proposed contributions on both TOMCAT-USER and
TOMCAT-DEV towards this end.

I'd like to combine the best features of these submissions, but wanted to
get some feedback and agreement on overall goals before doing so.  Here's
my list so far:

* Usable via JNDI 1.2 (or the JNDI classes built in to J2SDK 1.3).

* Does not interfere with existing use of JNDI APIs inside Catalina,
  or in user web apps.

* Pluggable initial context factory, and factory initialization
  parameters (so you can use any JNDI-accessible service you want).

* Configurable access to the internal data elements and attributes,
  so we don't have to predefine the structure (in the same way that
  JDBCRealm lets you configure table and column names).

* Reuse functionality in existing Realm implementations as appropriate
  (may cause a little minor refactoring along the way).

* Support for two major modes of operation:

  * SYSTEM LOGIN.  Realm implementation binds itself to the server using
    a system-level username/password, then reads the username and password
    attributes to perform authentication (analogous to how JDBCRealm
    works).  Would also support the optional digesting functionality that
    JDBCRealm supports.

  * USER LOGIN.  Realm implementation attempts to bind to the server
    using the username and password specified by the user.  If this is
    successful, the user is considered to be authenticated, and the
    associated roles are looked up.

Comments?  Questions?  Changes?


----- Original Message -----
From: "Jonathan Eric Miller" <>
To: "Tomcat User List" <>
Sent: Thursday, August 16, 2001 5:25 PM
Subject: JNDIRealm questions

> I'm currently looking at trying to use JNDIRealm for authentication and
> come up with a number of questions. I'm wondering if anyone knows the
> answers to any of the following questions.
> 1. Does anyone have it working that can provide an example entry of what
> should go in server.xml and also an example entry for a user (and a role,
> separate entry is required for that)?
> 3. What are the specific digest formats that are supported with regard to
> the userPassword attribute? Clear-text and MD5, or are there more? Does it
> support crypt? Also, does it check all userPassword values or only one?
> 2. Is it possible to get it to bind as the user being authenticated and
> require access to the userPassword attribute? If not, why? I'm guessing
> performance, but, this is problematic because it requires the password to
> in a specific format. Also, it is less secure since the password is sent
> over the wire even if it is encrypted and it won't work with directories
> such Active Directory which won't let you query the password attribute.
> 4. Does it query the server for each page request, or does it do caching?
> Jon

View raw message