On Thu, 23 Aug 2001, Jonathan Eric Miller wrote:
> Date: Thu, 23 Aug 2001 15:08:12 -0500
> From: Jonathan Eric Miller <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: JNDIRealm questions
>
> 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.
>
> Jon
>
I'm about halfway through a new HOWTO page that covers all three realm
implementations -- it should be done by next week. It will need to
include more than one example, because there's more than one "usual" way
that people populate their LDAP servers.
Craig
>
> [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?
>
> Craig
>
>
>
> ----- Original Message -----
> From: "Jonathan Eric Miller" <[EMAIL PROTECTED]>
> To: "Tomcat User List" <[EMAIL PROTECTED]>
> Sent: Thursday, August 16, 2001 5:25 PM
> Subject: JNDIRealm questions
>
>
> > I'm currently looking at trying to use JNDIRealm for authentication and
> I've
> > 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,
> if
> > 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
> not
> > require access to the userPassword attribute? If not, why? I'm guessing
> > performance, but, this is problematic because it requires the password to
> be
> > in a specific format. Also, it is less secure since the password is sent
> out
> > 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
> >
> >
> >
>
>
