Re: [PATCH] change jndi auth in tomcat

[John Holman]

Carsten

LDAP authentication with a bind is supported in the JNDIRealm included 
with Tomcat 4.1

John.


Carsten Burghardt wrote:

Hi,

I tried to get a ldap-authentification with domino but noticed that the 
current code (I checked tomcat 4.0.6 so if this is obsolete in a newer 
version forgive me) checks the given password with the retrieved one. This 
doesn't work as domino uses a different hash algorithm.
So I changed the getUserDN method from the JNDIRealm to auth with a bind.

Here's my code:

-
   protected String getUserDN(DirContext context,
  String username, String credentials)
   throws NamingException {

   if (debug >= 2)
   log("getUserDN(" + username + ")");
   if (username == null)
   return (null);
   if ((userFormat == null) || (userPassword == null))
   return (null);

   // Retrieve the user password attribute for this user
   String dn = userFormat.format(new String[] { username });
   if (debug >= 3)
   log("  dn=" + dn);

   context.addToEnvironment(Context.SECURITY_PRINCIPAL, dn);
   context.addToEnvironment(Context.SECURITY_CREDENTIALS, credentials);
   if (debug >= 3)
   log("Doing a lookup");
   Object user = context.lookup(dn);
   if (user == null)
   {
 log("Lookup failed");
 return (null);
   }

   return (dn);

   }
-

 



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

Re: Absolute fields required for JDBC & JNDI Realm pages in adminwebapp

[John Holman]

Amy Roh wrote:

> I just committed fixes to validate only className and connectionURL and also to
> check either userPattern or userSearch is specified but not both.

Thanks!

> I don't think any change to JNDIRealm is necessary since I changed admin so that
> it doesn't replace null values with "" for all configuration attributes
> anymore.  Could you see if everything is ok now?  I'll commit the changes to
> Tomcat 5 once I make sure it works correctly.

Sounds good, but I'm afraid I won't be able to do this for about 10 days 
... off on holiday early tomorrow. I'll check as soon as I get back.

Would it be too late for the changes to go into TC 4.1?


> I still need someone to comment on other realms so I can make them more
> "user-friendly".
> 
> Thanks,
> Amy


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

Re: Absolute fields required for JDBC & JNDI Realm pages in adminwebapp

[John Holman]

Amy

Yes - much too strict for JNDIRealm! The only configuration attributes 
that should always be specified for this realm are className and 
connectionURL. In addition either userPattern or userSearch must be 
specified (but not both). Other attributes either have default values, 
or not specifying them is itself significant (e.g. if userPassword is 
not specified the realm attempts to bind as the user rather than 
retrieve the user's password). (Note that the realm docs on the website 
are out of date, but the CVS and 4.1.8+  releases have new documentation 
which covers all of this).

In this connection, there is a problem with the admin application, which 
when it writes out a new version of the server.xml file converts all 
attributes that are unspecified by the user (e.g. in the original 
server.xml file) to attributes that are specified and have the empty 
string as their value This breaks JNDIRealm at the moment, and perhaps 
some other components as well (e.g. other realms).

However  I suspect this might be awkward to fix because of the way web 
forms work. If you can confirm that the admin app will continue to 
behave in this way (replacing null values with "" for all configuration 
attributes) then I can send you a patch for JNDIRealm to treat these 
values as equivalent. Configuration code in other components might also 
need to change - e.g. RealmBase decides whether a digest is being used 
by testing the value of the digest attribute against null, and throws an 
exception if it gets the empty string, since this is not null but not 
the name of a known digest algorithm either.

John


Amy Roh wrote:

> JDBC and JNDI Realms have many attributes.  What's the minimum list of 
> attributes to enable these two Realms?  I'll need to know the minimum 
> required list of attributes to validate the realm pages in admin 
> webapp.  Currently, it's validating all the fields as required which I 
> think is too strict.
>
> Thanks,
> Amy
>
>
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
>



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

Re: cvs commit: jakarta-tomcat-site/xdocs index.xml

[John Holman]

The Tomcat 4.1 documents referenced on the index.html page are not up to 
date (e.g. jndi-datasource-examples-howto, realm-howto).

John.


[EMAIL PROTECTED] wrote:
> remm2002/08/11 08:35:27
> 
>   Modified:docs index.html
>xdocsindex.xml
>   Log:
>   - Update site (finally).
>   
>   Revision  ChangesPath
>   1.26  +78 -27jakarta-tomcat-site/docs/index.html
>   
>   Index: index.html
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-site/docs/index.html,v
>   retrieving revision 1.25
>   retrieving revision 1.26
>   diff -u -r1.25 -r1.26
>   --- index.html  11 May 2002 17:27:44 -  1.25
>   +++ index.html  11 Aug 2002 15:35:27 -  1.26
>   @@ -158,12 +158,24 @@

...



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

Patch for security problem

[John Holman]

Bug 11210 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11210) is a 
security problem which could have serious effects for people using 
JNDIRealm with the Netscape/iPlanet JNDI LDAP provider 
 (com.netscape.jndi.ldap.LdapContextFactory). The default provider 
(com.sun.jndi.ldap.LdapCtxFactory) works OK.

I believe the problem is due to a failure of the Netscape/iPlanet 
provider to conform to the JNDI 1.2 specification - see the bugzilla 
report for details. However, getting that fixed is likely to take a 
while. The bug report includes a patch to JNDIRealm which avoids the 
problem. Could someone please have a look at it and hopefully commit it? 
(Remy has been committing my JNDIRealm patches but now that he's on 
holiday/has left Sun I'm not sure how things stand).

Thanks, John



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

Re: JNDIRealm in v4.1

[John Holman]

Sean

JNDIRealm in 4.1 does include an option to search the directory for the 
user's entry, very much along the lines you suggest (except the
directory connection is persistent). Unfortunately much of the 
documentation has still not been updated so this is less than obvious - and 
the spec probably doesn't reflect this functionality either. In the 
meantime have a look at the Java doc for JNDIRealm - and there is some info 
in the realm configuration page.

John.


At 21:49 21/06/02, you wrote:
>Hello.
>
>I just re-read the functional specs for the JNDIRealm in version 4.1
>(http://jakarta.apache.org/tomcat/tomcat-4.1-doc/catalina/funcspecs/fs-jndi-realm.html)
>
>I am relatively new to LDAP, so I apologize if my questions are stupid.
>However, I am a bit confused as to the Username Login Mode
>functionality.  Without an anonymous connection to the directory service
>always open as in the Administrator Login Mode, does that imply that an
>exact DN pattern must be supplied as a realm parameter, and the user's
>login substituted for the {0} placeholder?
>
>My client has a very large NDS directory, with users organized under
>many different geographic-based organizational units.  However, users
>from the entire enterprise will be accessing the application.
>Therefore, having a user DN pattern as a configuration parameter would
>not work, because the DN pattern will be different for users from
>different organizational units.
>
>Thus, I felt compelled to write my own realm using JNDIRealm as a
>starting point, with the following processing:
>
>Lifecycle Functionality
>
>The following processing must be performed when the start() method is
>called:
>
> * Establish a connection to the configured directory server, using
>an anonymous connection (NOT a configured system administrator username
>and password as in the current JNDIRealm).
>
>The following processing must be performed when the stop() method is
>called:
>
> * Close any opened connections to the directory server.
>
>Method authenticate() Functionality
>
>When authenticate() is called, the following processing is required:
>
> * Using the anonymous connection, perform a directory search to
>obtain the user's full DN, based on a simple search pattern such as
>(cn={0}).
> * Attempt to bind to the directory server, using the full DN found
>above and the password provided by the user.
> * If the user was not authenticated, release the allocated
>connection and return null.
> * Acquire a List of the security roles assigned to the authenticated
>user by performing a search using the authenticated user's connection.
> * Release the authenticated user's connection.
> * Construct a new instance of class
>org.apache.catalina.realm.GenericPrincipal, passing as constructor
>arguments: this realm instance, the authenticated username, and a List
>of the security roles associated with this user.
> * Return the newly constructed GenericPrincipal.
>
>So here is the question:
>
>Have I misunderstood the functional specs for the JNDIRealm in v 4.1, or
>is the omission of a "search" processing step prior to attempting to
>bind as the user a serious omission in the functional requirements?  At
>least equally likely, has my lack of mature LDAP knowledge lead me to
>make incorrect assumptions that make the whole point moot?
>
>BTW, anyone is welcome to my code if they want it.  Just let me know.
>
>Sean Dillon
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 


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

JNDIRealm maintenance

[John Holman]

Remy

I wrote the original JNDIRealm which Craig committed with modifications, 
made major enhancements in March this year and submitted documentation 
updates a couple of times since (which have still not been committed).

I'm prepared to maintain this component, but the difficulty of finding 
anyone with the time and interest to review and commit patches is a real 
problem, especially since Craig's involvement has reduced.  Commit 
access would help - but the recent discussion in Jakarta indicates that 
more is expected of a committer than maintaining a single component so 
maybe that is not appropriate. Any suggestions?

Regards, John.


[EMAIL PROTECTED] wrote:

>DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
>RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
>.
>ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
>INSERTED IN THE BUG DATABASE.
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9705
>
>Extra LDAP searches occur during JNDIRealm authentication
>
>
>
>
>
>--- Additional Comments From [EMAIL PROTECTED]  2002-06-07 22:56 ---
>AFAIK, nobody is currently actively maintaining the JNDI realm. So the changes 
>you propose won't be implemented anytime soon unless you submit some patches.
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>  
>



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

[PATCH] Documentation for JNDI Realm

[John Holman]

I submitted some major changes to the JNDI Realm earlier this year, which 
Craig committed in March. I also sent updates for the realm how-to and 
realm configuration docs to this list shortly afterwards, but those have 
not yet been committed. The current how-to doc in particular does not cover 
any of the new features.

So, I'm sending the revised realm-howto.xml and config/realm.xml documents 
again. Because the revisions are extensive I've sent the actual documents 
rather than diffs - but if anyone is prepared to commit them and would 
prefer diffs I can certainly send those instead.

I'll also report this as a bug in the hope it will act as a reminder.

Thanks, John.


realm-howto.xml
Description: application/xml


config-realm.xml
Description: application/xml

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

[PATCH] JNDIRealm documentation

[John Holman]

I've attached updates for the realm configuration and howto docs to cover 
recent changes in the JNDIRealm. The patch for the config doc is a bit 
different from the one I submitted on Sunday, so please ignore the earlier 
version. The howto changes are quite extensive, but I thought it worth 
going into some detail to explain how the directory realm works and maybe 
anticipate questions that are likely to come up.

Craig, would you look them over and submit if OK.

By the way I don't know whether the plan would be to include the new realm 
in a 4.0 release or wait until 4.1. It should be entirely backwards 
compatible, and I've tested it lightly with
4.0.2, but obviously it's adding new features rather than fixing bugs.

Thanks, John.



At 18:37 15/03/02, [EMAIL PROTECTED] wrote:
>craigmcc02/03/15 10:37:42
>
>   Modified:catalina/src/share/org/apache/catalina/realm JNDIRealm.java
>webapps/tomcat-docs/config realm.xml
>   Log:
>   Major enhancements to the JNDIRealm implementation.  While remaining
>   backwards compatible with the previous implementation, the following new
>   functionality is supported:
>
>   John, thanks for your patience with me on getting this patch committed!
>   Could you also make sure that I got the facts right on my edits to the
>   configuration docs?  (A patch to tomcat-docs/realm-howto.xml to explain
>   the new options would also be cool.)
>
>   Submitted by: John Holman 
>


Index: realm-howto.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/tomcat-docs/realm-howto.xml,v
retrieving revision 1.4
diff -u -r1.4 realm-howto.xml
--- realm-howto.xml 3 Jan 2002 13:56:38 -   1.4
+++ realm-howto.xml 21 Mar 2002 22:28:56 -
@@ -7,7 +7,8 @@
 &project;
 
 
-Craig R. McClanahan
+Craig
+R. McClanahan
 Realm Configuration HOW-TO
 
 
@@ -319,63 +320,175 @@
 Introduction
 
 JNDIRealm is an implementation of the Tomcat 4
-Realm interface that looks up users in a directory server
-accessed by a JNDI provider (typically, the standard LDAP provider that
-is available with the JNDI API classes).  There is substantial configuration
-flexibility that lets you adapt to the existing schema inside your directory
-server, as long as it conforms to the following requirements:
-
-Each user that can be authenticated is represented by an individual
-element in the top level DirContext that is accessed
-via the connectionURL attribute.
-The user element must have the following characteristics:
-
-The distinguished name (dn) attribute of this element
-contains the username that is presented for authentication.
-There must be an attribute (identified by the userPassword
-attribute of our Realm element) that contains the user's
-password, either in clear text or digested (see below for more info).
-
-
-Each group of users that has been assigned a particular role is
-represented by an individual element in the top level
-DirContext that is accessed via the
-connectionURL attribute.
-The user group element must have the following characteristics:
-
-The set of all possible groups of interest can be selected by an LDAP
-search pattern configured by the roleSearch attribute
-of our Realm element.
-The roleSearch pattern optionally includes pattern
-replacements "{0}" for the distinguished name, and/or "{1} for the
-username, of the authenticated user for which roles will be
-retrieved.
-The roleBase attribute can be set to the element that
-is the base of the search for matching roles.  If not specified,
-the entire directory context will be searched.
-The roleSubtree attribute can be set to true
-if you wish to search the entire subtree of the directory context.
-The default value of false requests a search of only the
-current level.
-The element includes an attribute (whose name is configured by the
-roleName attribute of our Realm element)
-containing the name of the role represented by this element.
-
-There must be an administrator username and password that Tomcat can
-use to establish a connection to the directory server, with at least
-read-only access to the information described above.  A future
-version of Tomcat will support an option to use the user's username and
-password to attempt this connection.
+Realm interface that looks up users in an LDAP directory
+server accessed by a JNDI provider (typically, the standard LDAP
+provider that is available with the JNDI API classes). The realm
+supports a variety of approaches to using a directory for
+authentication.
+
+Connecting to the directory
+
+The realm's connection to the directo

[PATCH} Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config realm.xml

[John Holman]

Craig,

At 18:37 15/03/02, you wrote:
>   John, thanks for your patience with me on getting this patch committed!
>   Could you also make sure that I got the facts right on my edits to the
>   configuration docs?  (A patch to tomcat-docs/realm-howto.xml to explain
>   the new options would also be cool.)

Thanks for somehow finding the time to commit it!. I've attached a patch 
for the
configuration docs.

I'll try to tackle the howto later this week.

John.




Index: realm.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/tomcat-docs/config/realm.xml,v
retrieving revision 1.3
diff -u -r1.3 realm.xml
--- realm.xml   15 Mar 2002 18:37:42 -  1.3
+++ realm.xml   17 Mar 2002 13:48:28 -
@@ -160,27 +160,54 @@
 
 The JNDI Directory Realm connects Catalina to
 an LDAP Directory, accessed through an appropriate JNDI driver,
-to perform lookups of usernames, passwords, and their associated
-roles.  Because the lookup is done each time that it is required,
-changes to the directory will be immediately reflected in the
-information used to authenticate new logins.
-
-A rich set of additional attributes lets you configure the required
-connection to the underlying directory, as well as the element and
-attribute names used to retrieve the required information:
+that stores usernames, passwords, and their associated roles. Changes to the
+directory are immediately reflected in the information used to
+authenticate new logins.
+
+
+The directory realm is flexible enough to accommodate a variety of
+approaches to using LDAP for authentication:
+
+
+The realm can either use a pattern to determine the user's
+distinguished name (DN) or search the directory to locate the
+user's directory entry.
+
+
+The realm can authenticate the user either by binding to the
+directory with the username and password specified by the user, or
+by retrieving the password from the user's entry and performing a
+comparison locally.
+
+
+Roles may be represented in the directory as explicit entries
+found by a directory search (e.g. group entries of which the user
+is a member), as the values of an attribute in the user's entry,
+or both.
+
+
+
+ A rich set of additional attributes lets you configure the
+required behaviour as well as the connection to the underlying
+directory and the element and attribute names used to retrieve
+information from the directory:
 
 
 
   
-The directory username to use when establishing the JNDI
-connection.  This attribute is required if you specify the
-userPassword property, and not used otherwise.
+The directory username to use when establishing a
+connection to the directory to search or retrieve
+information. If not specified an anonymous connection is made,
+which is often sufficient unless you specify the
+userPassword property.
   
 
   
-The directory password to use when establishing the JNDI
-connection.  This attribute is required if you specify the
-userPassword property, and not used otherwise.
+The directory password to use when establishing a
+connection to the directory to search or retrieve
+information. If not specified an anonymous connection is made,
+which is often sufficient unless you specify the
+userPassword property.
   
 
   
@@ -194,28 +221,38 @@
 assumes that the standard JNDI LDAP provider will be utilized.
   
 
-  
-The base directory element for performing role searches.
+  
+The base directory entry for performing role searches. If
+not specified a role search does not take place and roles are taken
+only from the attribute in the user's entry specified by the
+userRoleName property.
   
 
   
-The name of the directory attribute to retrieve when selecting
-the assigned roles for a user.  If not specified, use the
-userRoleName property to specify the name of an
-attribute, in the user's entry, that contains zero or more role
-names assigned to this user.
-  
-
-  
-The LDAP search expression to use when selecting roles for a
-particular user, with {0} marking where the actual
-username should be inserted.
-  
-
-  
-Set to true to search subtrees of the elements
-selected by the roleSearch search expression.  Set
-to false to not search subtrees.
+The name of the attribute that contains role names in the
+directory entries found by a role search. In addition you can
+use the userRoleName property to specify the name
+of an attribute, in the user's entry, containing additional
+role names.  If role

Re: {PATCH] Enhanced JNDI realm

[John Holman]

At 20:11 01/03/02, Jonathan Eric Miller wrote

>Hi John,
>
>I'm glad to see that you have come up with a patch for JNDIRealm which
>allows users to be authenticated by a bind instead of having to query for a
>password.
>
>One thing that I'm wondering about though, with regard to your
>implementation, do you have to use groups? Or, can you specify a filter in
>order to determine which users are authorized? The reason why I'm curious is
>that I want to use JNDIRealm against our University-wide LDAP server.
>However, I don't have the ability to create groups in the directory. It
>would be nice if you could just specify a filter.


Yes, the patch lets you specify an arbitrary search filter to locate users 
in the directory, so it would be
possible to limit authentication (and therefore authorization) that way 
provided the criteria you want to filter on are already present
in the directory.

In addition, if you want to authorize through roles, a new "userRoleName" 
parameter can be used to define an attribute of the user that contains role 
name(s). These will be used in addition to any roles found by searching for 
explicit role entries (e.g. represented as groups).

In fact, you don't *have* to use groups to represent roles even in the 
existing implementation (the new parameter mostly just makes that more 
explicit).  For example suppose you wanted to limit access to people within 
a particular department. If people have an "ou" attribute whose value is 
the name of their department, you could arrange for them to have a role 
that is the name of their department by setting roleBase to the entry 
containing the users, roleSearch to "(&(uid = {1})"), and roleName to "ou".

>Also, would it be possible to integrate SSL/TLS support in as well?


I'm hoping to do that - but waiting to see whether my patch will be 
committed. It should be easy to support, but I don't actually have a 
directory server set up to test it at present.

John.


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

{PATCH] Enhanced JNDI realm

[John Holman]

Craig

I've attached a patch to enhance the current JNDI realm implementation. 
This includes three features that have been requested a number of times and 
appear in the draft functional specification:

** the realm can authenticate by binding to the directory as the user. This 
mode of operation is usually to be preferred unless HTTP digest 
authentication is required. The realm will automatically authenticate in 
this way if the "userPassword" configuration attribute is not specified. 
The "connectionName" and "connectPassword" properties are used
when searching the directory or retrieving role information. In this mode, 
anonymous authentication is often sufficient, in which case these need not 
be specified.

** the realm can search the directory for the user's entry. It will do this 
if the "userPattern" configuration attribute is not specified.

Three new configuration parameters control the search for the user's 
directory entry:

userSearch - a pattern specifying the LDAP search filter for selecting 
users. Use {0} to substitute in the username.

userBase - the base element for user searches. If not specified the top 
level element in the directory context will be used.

useSubtree - set to true if you want user searches to search subtrees of 
the element selected by userBase. The default value of false causes only 
the top level element to be searched.


** the realm can combine roles held as the values of an attribute in the 
user's entry with those retrieved from a search for roles. The search for 
roles takes place as before. If the roleSearch configuration attribute is 
not specified the realm will look only in the user's entry for roles.

This feature uses one new configuration attribute:

userRoleName - the name of an attribute in the user's entry containing the 
names of roles. If not specified the directory is searched for roles as before.

Note that the new configuration interface is backwards compatible with the 
current JNDIRealm. For existing users the realm will behave just as it did 
before - no configuration changes are required. The existing documentation 
is still accurate about the subset of functionality it describes.

Here is a sample realm configuration that demonstrates all three new 
features. It is assumed that an anonymous bind is sufficient to search the 
directory for the user
and retrieve the role information. The user is found by searching the 
directory and authenticated by binding to the directory with the 
credentials presented by the user. Role names are contained both in the 
"memberOf" attribute of the user's own directory entry and in the "cn" 
attribute of group entries to which the user belongs

   ldap://localhost:389";
  userBase="ou=people,dc=mycompany,dc=com"
  userSearch="(uid={0})"
  userRoleName="memberOf"
  roleSearch="(uniqueMember={0})"
  roleBase="ou=groups,dc=mycompany,dc=com"
  roleName="cn"
  roleSubtree="true"
   />



I've not addressed issues of connection management etc in this patch, 
though there is certainly room for improvement (context pooling etc). In a 
previous message you mentioned leveraging the "global JNDI resources" 
capabilities for that, and Tony Danbura has also expressed an interest in 
this area. However the enhancements in this patch are independent of that 
issue, and should not complicate it. In particular, note that the "bind 
mode" functionality is implemented in a way that still uses a single 
directory context that can be returned to the pool. This is achieved by 
changing the security environment of the context before and after binding, 
rather than creating a different context for the bind. With an LDAP v3 
server this should be an efficient approach since the underlying connection 
to the directory server does not change. An LDAP v2 server must create a 
new connection for each bind operation, so context pooling will not be so 
effective, but that does not affect the logic.

I'd be very grateful if you would take a look at this patch and hopefully 
submit it. If it is accepted I promise I'll update the documentation to 
cover the new features!

Thanks, John.










Index: JNDIRealm.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
retrieving revision 1.5
diff -u -r1.5 JNDIRealm.java
--- JNDIRealm.java  7 Sep 2001 20:45:12 -   1.5
+++ JNDIRealm.java  1 Feb 2002 21:17:50 -
@@ -68,6 +68,9 @@
 import javax.naming.NameNotFoundException;
 import javax.naming.NamingEnumeration;
 import javax.naming.NamingException;
+import javax.naming.NameParser;
+import javax.naming.Name;
+import javax.naming.AuthenticationException;
 import javax.naming.directory.Attribute;
 import javax.naming.directory.Attributes;
 import javax.naming.directory.DirContext;
@@ -87,18 +90,39 @@
  * 
  * Each user that ca

Re: Proposal for a new realm module for tomcat

[John Holman]

Tony

I had a look at the documentation for your LDAPRealm and apart from the HA 
features it looks very similar to my original JNDIRealm proposal both in 
features and configuration options. I couldn't see any source code on your 
site though.

I sent a revised functional specification to the tomcat-dev list a few 
weeks ago elaborating on what I think are the most important features 
(mostly authentication via simple bind and searching for the user's entry 
when necessary) but got no response. I'd like to see those features in 
JNDIRealm one way or the other but don't know how to make progress with 
getting it accepted.

John.


At 03:52 26/01/02, you wrote:
>John:
>Sorry I have been really busy and have not had a chance to followup on my 
>emails.
>The original author of the sdk is actually back doing continuing work on 
>it.  Yes
>indeed you can replace the ldap provider with the one from iplanet and it 
>gets you
>much better session and connection recovery.
>
>I actually spent a bit of time working on a native ldap implementation, 
>not using
>jndi, and put in conn pooling and other features.  I think I would like to 
>look at
>rolling these into the base line jndi implementation as well and leave 
>folks with
>an option to choose either realm implementation they would like to use 
>with tomcat.
>
>How about I pick up the jndi module and work on it a bit to get some of these
>features in.  BTW if you want to take a look at the native ldap realm 
>module you
>can grab it from my web site.  http://www.dahbura.com/ldap  I thought if folks
>liked it and wanted to use it we could include it in the base build for 
>tomcat.
>
>Should I just take the current snapshot in there and work on it or does it 
>need to
>be checked out?
>
>Tony
>
>
>John Holman wrote:
>
> > At 21:41 04/01/02, Tony Dahbura wrote:
> > >John:
> > >There are other issues with the JNDI implementation that we have run into
> > >with some
> > >commercial high end load balancers.  It has to do with connection
> > >re-authentication
> > >and sessions getting dropped on non used connections.
> > >  I did some work on the actual
> > >API for the Netscape LDAP implementation and we puti n handling of this
> > >situation
> > >as well. It really from a programmer perspective looks the same but
> > >handles a lot
> > >of low level details with regards to server connections that work better
> > >in a many
> > >HA settings.
> >
> > Our own requirements are quite modest and this has not been a problem so
> > far. However I'm sure others would benefit from a robust and high
> > performing implementation.
> >
> > I know little about the Netscape Directory SDK, but was under the
> > impression that the API it offers to programmers for access to directory
> > services is very different to JNDI. However, looking at the Mozilla site
> > today I noticed that an LDAP provider for JNDI is included in version 4.1
> > of the SDK. Were you perhaps contemplating using JNDI with this Netscape
> > LDAP provider rather than the Netscape LDAP API itself? If so, does the
> > Netscape LDAP provider for JNDI have advantages over Sun's version (other
> > than being open source of course) and are there still active developers?
> > (My impression was that there has been little activity over the last year).
> >
> > My feeling initially is that if we can work around any disadvantages it
> > would be best to stay with the JNDI API to directory services but allow for
> > a choice of LDAP providers.
> >
> > >I would love to work with you on the proposal for this. As I have 
> indicated I
> > >started a wish list of things to code in this realm module you hit 
> many of the
> > >points of what I was looking at doing.  I agree for many folks the JNDI
> > >implementation can suit much of their needs, I have just run across some
> > >folks that
> > >wanted better support for more diverse network environments.
> >
> > I'd be happy to cooperate on this.
> >
> > >Let's flesh this out and see what comes from it.
> > >
> > >Tony
> > >
> > >
> > >John Holman wrote:
> > >
> > > > At 04:28 04/01/02, Tony Dahbura wrote:
> > > > >I would like to see about proposing the development of an 
> additional realm
> > > > >module for tomcat.  I have begun some design on this and think it will
> > > > >meet the
> > > > >needs of many folks out there utilizing LDAP.  I would like to 
> propose a

Re: Functional spec for JNDI Realm

[John Holman]

Tony

t 02:58 09/01/02, Tony Dahbura wrote:
>I think what Craig is referring to for role retrieval is the idea that the 
>roles a
>user is a member of are stored in the user's directory entry.  This 
>approach allows
>entry to a group by adding that attribute to the specific user entry.
>
>The role retrieval would have the option to look a list of roles or to 
>look at the
>user's entry to determine role membership.


It is certainly possible to hold the roles as the values of an attribute in 
the user's directory entry. However, as in fact I mentioned in my original 
query to Craig, this is a special case that is already covered by the 
current approach. For example, if the roles are held in an attribute of the 
user called "roles" whose values are the names of the roles the user is a 
member of, the current realm might be configured with

roleName="roles"
roleSearch="(uid = {1})"
roleBase= [ dn for the root of the directory tree containing the user entries ]

The search for roles would find the user's directory entry, since {1} is a 
placeholder for the username, and retrieve the values of the roleNames 
attribute.

Of course some optimisation is possible in this special case. For example, 
in "Administrator Login" mode the roles could be retrieved at the same time 
as the password, although this would complicate the code to some extent.

I'd agree that we should perhaps recognize this special case by saying that 
if the roleBase and roleSearch parameters are not defined then the roles 
are assumed to be held explicitly in the user's entry. This would simplify 
configuration for the user. However, I don't know how common this use case 
is in practice. As far as I know, there is no standard attribute for this 
purpose, so the user would have the extend the directory schema to 
accommodate it, which might be a deterrant to some.


John.



>Tony
>
>
>John Holman wrote:
>
> > Craig
> >
> > I understand (and prefer!) the "bind" approach to authentication. Its the
> > two approaches to role retrieval that has me puzzled.
> >
> > John
> >
> > At 17:08 08/01/02, Craig R. McClanahan wrote:
> > >Hi John,
> > >
> > >Some LDAP servers are configured to never allow the userPassword attribute
> > >be accessed at all.  The only way to authenticate, in this approach, is to
> > >attempt an LDAP "bind" using the username and password values specified by
> > >the user of the web application -- so that each authentication attempt
> > >becomes a separate bind.  If the bind succeeds, authentication was
> > >successful -- otherwise it failed.
> > >
> > >I know that the old Netscape Enterprise Server used LDAP this way, and I
> > >imagine that the current iPlanet ones do as well.  But we don't currently
> > >support this mode in JNDIRealm.
> > >
> > >As an additional new feature, I am looking to leverage the "global JNDI
> > >resources" capabilities (in the HEAD branch only) that would let us
> > >declare a global connection pool (for either JNDI connections or JDBC
> > >connections) in server.xml, and then use it from within a Realm *and* an
> > >application if the system administrator sets things up to allow this.
> > >That should let us improve overall performance -- at least on the "log in
> > >with the system username/password" mode that we currently support.
> > >
> > >Craig
> > >
> > >
> > >On Tue, 8 Jan 2002, John Holman wrote:
> > >
> > > > Date: Tue, 08 Jan 2002 14:25:16 +
> > > > From: John Holman <[EMAIL PROTECTED]>
> > > > To: [EMAIL PROTECTED]
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: Functional spec for JNDI Realm
> > > >
> > > > Craig
> > > >
> > > > After a long delay, I'm looking at your proposed functional spec 
> for the
> > > > Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the
> > > > "Adminstrator Login Mode Functionality" section:
> > > >
> > > >  > The following approaches should be supported [ for retrieving 
> the roles
> > > > associated with an authenticated user ]
> > > >  >
> > > >  > Retrieve a specified attribute (possibly multi-valued) from an LDAP
> > > > search expression, with a replacement placeholder
> > > >  > for the DN or username of the user.[Current]
> > > >  >
> > > >  > Retrieve a set of role names that are defined implicitly (by 
&g

Revised specification for JNDIRealm

[John Holman]

Craig

I've attached a revised version of your proposed functional specification 
for JNDIRealm. The main changes are to spell out in more detail options for 
determining the user's distinguished name, and expanding on the 
functionality of the User Login mode. I've not said much about determining 
roles, pending clarification!

Hope it's OK to send the revised document as an attachment to the list - a 
patch would not have been significantly smaller.

Comments very welcome.

John.


fs-jndi-realm.xml
Description: application/xml

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

Re: Functional spec for JNDI Realm

[John Holman]

Craig

I understand (and prefer!) the "bind" approach to authentication. Its the 
two approaches to role retrieval that has me puzzled.

John

At 17:08 08/01/02, Craig R. McClanahan wrote:
>Hi John,
>
>Some LDAP servers are configured to never allow the userPassword attribute
>be accessed at all.  The only way to authenticate, in this approach, is to
>attempt an LDAP "bind" using the username and password values specified by
>the user of the web application -- so that each authentication attempt
>becomes a separate bind.  If the bind succeeds, authentication was
>successful -- otherwise it failed.
>
>I know that the old Netscape Enterprise Server used LDAP this way, and I
>imagine that the current iPlanet ones do as well.  But we don't currently
>support this mode in JNDIRealm.
>
>As an additional new feature, I am looking to leverage the "global JNDI
>resources" capabilities (in the HEAD branch only) that would let us
>declare a global connection pool (for either JNDI connections or JDBC
>connections) in server.xml, and then use it from within a Realm *and* an
>application if the system administrator sets things up to allow this.
>That should let us improve overall performance -- at least on the "log in
>with the system username/password" mode that we currently support.
>
>Craig
>
>
>On Tue, 8 Jan 2002, John Holman wrote:
>
> > Date: Tue, 08 Jan 2002 14:25:16 +
> > From: John Holman <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Functional spec for JNDI Realm
> >
> > Craig
> >
> > After a long delay, I'm looking at your proposed functional spec for the
> > Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the
> > "Adminstrator Login Mode Functionality" section:
> >
> >  > The following approaches should be supported [ for retrieving the roles
> > associated with an authenticated user ]
> >  >
> >  > Retrieve a specified attribute (possibly multi-valued) from an LDAP
> > search expression, with a replacement placeholder
> >  > for the DN or username of the user.[Current]
> >  >
> >  > Retrieve a set of role names that are defined implicitly (by selecting
> > principals that match a search pattern) rather
> >  > than explicitly (by finding a particular attribute value). [Requested]
> >
> > The existing code certainly implements the first approach, which I assume
> > could be rephrased as
> >
> > Retrieve the values of a specified attribute from all directory entries
> > matching an LDAP search filter expression. The search expression is
> > constructed by substituting the user's DN and/or username into a string
> > pattern specified as the roleSearch configuration property.
> >
> > However I guess I don't understand what you mean by the second approach. Do
> > you have a specific example? I would have thought that the current approach
> > covers all use cases (although admittedly the implementation may not be
> > optimal for the special case in which role names are held explicitly as the
> > values of an attribute in the user's directory entry).
> >
> > Cheers, John.
> >
> >
> >
> >
> >
> >
> >



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Functional spec for JNDI Realm

[John Holman]

Craig

After a long delay, I'm looking at your proposed functional spec for the 
Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the 
"Adminstrator Login Mode Functionality" section:

 > The following approaches should be supported [ for retrieving the roles 
associated with an authenticated user ]
 >
 > Retrieve a specified attribute (possibly multi-valued) from an LDAP 
search expression, with a replacement placeholder
 > for the DN or username of the user.[Current]
 >
 > Retrieve a set of role names that are defined implicitly (by selecting 
principals that match a search pattern) rather
 > than explicitly (by finding a particular attribute value). [Requested]

The existing code certainly implements the first approach, which I assume 
could be rephrased as

Retrieve the values of a specified attribute from all directory entries 
matching an LDAP search filter expression. The search expression is 
constructed by substituting the user's DN and/or username into a string 
pattern specified as the roleSearch configuration property.

However I guess I don't understand what you mean by the second approach. Do 
you have a specific example? I would have thought that the current approach 
covers all use cases (although admittedly the implementation may not be 
optimal for the special case in which role names are held explicitly as the 
values of an attribute in the user's directory entry).

Cheers, John.







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

Re: Proposal for a new realm module for tomcat

[John Holman]

At 21:41 04/01/02, Tony Dahbura wrote:
>John:
>There are other issues with the JNDI implementation that we have run into 
>with some
>commercial high end load balancers.  It has to do with connection 
>re-authentication
>and sessions getting dropped on non used connections.
>  I did some work on the actual
>API for the Netscape LDAP implementation and we puti n handling of this 
>situation
>as well. It really from a programmer perspective looks the same but 
>handles a lot
>of low level details with regards to server connections that work better 
>in a many
>HA settings.

Our own requirements are quite modest and this has not been a problem so 
far. However I'm sure others would benefit from a robust and high 
performing implementation.

I know little about the Netscape Directory SDK, but was under the 
impression that the API it offers to programmers for access to directory 
services is very different to JNDI. However, looking at the Mozilla site 
today I noticed that an LDAP provider for JNDI is included in version 4.1 
of the SDK. Were you perhaps contemplating using JNDI with this Netscape 
LDAP provider rather than the Netscape LDAP API itself? If so, does the 
Netscape LDAP provider for JNDI have advantages over Sun's version (other 
than being open source of course) and are there still active developers? 
(My impression was that there has been little activity over the last year).

My feeling initially is that if we can work around any disadvantages it 
would be best to stay with the JNDI API to directory services but allow for 
a choice of LDAP providers.

>I would love to work with you on the proposal for this. As I have indicated I
>started a wish list of things to code in this realm module you hit many of the
>points of what I was looking at doing.  I agree for many folks the JNDI
>implementation can suit much of their needs, I have just run across some 
>folks that
>wanted better support for more diverse network environments.

I'd be happy to cooperate on this.


>Let's flesh this out and see what comes from it.
>
>Tony
>
>
>John Holman wrote:
>
> > At 04:28 04/01/02, Tony Dahbura wrote:
> > >I would like to see about proposing the development of an additional realm
> > >module for tomcat.  I have begun some design on this and think it will
> > >meet the
> > >needs of many folks out there utilizing LDAP.  I would like to propose a
> > >native
> > >LDAP realm module that allows utlization of ldap features that may or may
> > >not be
> > >possible through the JNDI layer.
> >
> > As far as I can see, writing a "native LDAP realm module" - if by that you
> > mean using the API provided by the Netscape directory SDK rather than Sun's
> > JNDI API - would make little difference to the functionality possible.
> > There may be performance benefits, though I have read conflicting reports
> > on that.
> >
> > >The items I am looking at designing into this module are:
> > >1-Connection pooling to support high performance access
> > >2-HA capabilities to support failover if a server goes away
> > >3-Authentication via the server rather than comparison of the passwords in
> > >digested forms (this option will also be supported)
> > >4-support for other realm group models (still checking into this).
> > >5-User location without DN identification (no need to be able to build the
> > >DN to
> > >find the user)
> > >6-SSL support for communications
> >
> > Some history ...
> >
> > The current JNDIRealm implementation in Tomcat 4 is based on code I
> > proposed back in April last year. I believe the existing implementation is
> > sufficiently flexible to cover most ways of representing group information
> > in the directory (item 4), and adding SSL support (item 6) should be
> > trivial. However item 3 (authentication by binding to the directory as the
> > user rather than by retrieving credentials and comparing them explicitly in
> > the realm) and feature 5 (essentially, finding the user's DN by searching
> > the directory on an arbitrary attribute) are not included. I think items 3
> > and 5 are essential if the module is to be of much practical use.
> >
> > In fact my original proposal did include much of the missing functionality
> > (though not the performance and availability enhancements you mention).
> > Craig made several significant improvements to the code before committing
> > it, but also removed support for items 3 and 5. I subsequently proposed a
> > patch restoring item 3, and planned to propose a second patch restoring
> > item 5 if the first patch was ac

Re: Proposal for a new realm module for tomcat

[John Holman]

At 04:28 04/01/02, Tony Dahbura wrote:
>I would like to see about proposing the development of an additional realm
>module for tomcat.  I have begun some design on this and think it will 
>meet the
>needs of many folks out there utilizing LDAP.  I would like to propose a 
>native
>LDAP realm module that allows utlization of ldap features that may or may 
>not be
>possible through the JNDI layer.

As far as I can see, writing a "native LDAP realm module" - if by that you 
mean using the API provided by the Netscape directory SDK rather than Sun's 
JNDI API - would make little difference to the functionality possible. 
There may be performance benefits, though I have read conflicting reports 
on that.

>The items I am looking at designing into this module are:
>1-Connection pooling to support high performance access
>2-HA capabilities to support failover if a server goes away
>3-Authentication via the server rather than comparison of the passwords in
>digested forms (this option will also be supported)
>4-support for other realm group models (still checking into this).
>5-User location without DN identification (no need to be able to build the 
>DN to
>find the user)
>6-SSL support for communications

Some history ...

The current JNDIRealm implementation in Tomcat 4 is based on code I 
proposed back in April last year. I believe the existing implementation is 
sufficiently flexible to cover most ways of representing group information 
in the directory (item 4), and adding SSL support (item 6) should be 
trivial. However item 3 (authentication by binding to the directory as the 
user rather than by retrieving credentials and comparing them explicitly in 
the realm) and feature 5 (essentially, finding the user's DN by searching 
the directory on an arbitrary attribute) are not included. I think items 3 
and 5 are essential if the module is to be of much practical use.

In fact my original proposal did include much of the missing functionality 
(though not the performance and availability enhancements you mention). 
Craig made several significant improvements to the code before committing 
it, but also removed support for items 3 and 5. I subsequently proposed a 
patch restoring item 3, and planned to propose a second patch restoring 
item 5 if the first patch was accepted. Craig's response was that we should 
first get agreement on top-level goals, and proposed a functional 
specification for the JNDI Realm which is included in the Tomcat release 
documentation. This spec includes two "login modes" which cover item 3, but 
says little about the other items.

As far as I know there has been no discussion of the spec since then, and 
it still has proposed status. So perhaps the next step before enhancing the 
existing module would be for the group to reach agreement about the 
required features and produce a revised spec. I'm afraid I never got round 
to proposing changes to the spec myself but now the subject has come up 
again I will try to have a go at it. (I'll probably need to look at the 
format of the source document, which is in some dialect of xml).

However, I don't know what the position would be about a completely new module.

Cheers, John.



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

Re: Suggested change to JNDIRealm

[John Holman]

Casey

Unless I misunderstand, I think the existing JNDIRealm will handle this. In
the roleSearch parameter, {1} is substituted by the username, so in your
example you could have

roleBase= [ basedn for user entries ]
roleName="memberof"
roleSearch = "(uid={1})"

This might involve an additional directory search though.

John.


- Original Message -
From: "Bragg, Casey" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 07, 2001 8:38 PM
Subject: Suggested change to JNDIRealm


> I've written a modification of
org.apache.catalina.realm.JNDIRealm.getRoles
> to allow for the following :
>
> If the realm descriptor's roleBase (in server.xml) is null or blank,
> JNDIRealm will retrieve the assigned roles list from the attribute owned
by
> the user's DN which is specified in roleName.  That's hard to read.  Here
is
> an example.
>
> Given an authenticated user with DN uid=FreakyWill,ou=mycompany
> Given that the node uid=FreakyWill,ou=mycompany contains the following
> attributes
>memberof=beerusers
>memberof=freakyusers
> Given the following Realm descriptor entries :
>roleBase=""
>roleName="memberof"
>
> JNDIRealm.getRoles will return the roles beerusers and freakyusers by
simply
> retrieving the userDN's memberof attribute.
>
> If roleBase is populated (not null + length>0), JNDI will maintain its
prior
> functionality to retrieve roles.
>
> Any comments?  My LDAP implementation requires this functionality.  Should
I
> submit this code to the tomcat project somehow?
>
> Thanks...
>
> ...Casey
>
> ==
> Casey Bragg - Software Engineer
> Allegiance Telecom, Inc.  Dallas, TX
> 469-259-2702 - [EMAIL PROTECTED]
> ==
>
>

Re: [PATCH] Catalina JNDIRealm - binding as the user

[John Holman]

When using a pattern the uid value or whatever that people enter is 
substituted into the pattern to generate the dn - users are not expected to 
enter the full dn. Search is needed however when the attribute whose value 
is entered by the user is not a component of the dn, or when users are held 
in the directory under more than one node.

I agree that when a directory is used for authentication it is usually safe 
to assume that the entered value is a unique identifier for an entry. An 
exception might arise though when users are held under multiple nodes - 
e.g. people are held under organisational units, and some people are 
employed by more than one unit.

At 04:48 17/05/01, Martin Smith wrote:
>My use of search then bind is searching for a non-DN "user ID" (like UID or
>mail, which is presumably unique) then binding witht he retrieved DN and
>password.  Can you imagine making people type in X.500-style user names
>
>Martin





>Torgeir Veimo wrote:
>
> > John Holman wrote:
> > >
> > > As said before I'd like to add the ability to search the directory 
> for the
> > > user's dn to cover cases when a fixed pattern will not work, but will 
> wait
> > > to see the fate of this patch before going ahead.
> >
> > Regarding the "search, then bind" authentication; what would be the
> > suggested behaviour when there are more than one returned dn from the
> > search? Should one try to authenticate as each of these, or
> > automatically assume not authenticated?
> >
> > --
> > - Torgeir

Re: [PATCH] Catalina JNDIRealm - binding as the user

[John Holman]

I was planning to fail authentication if more than one entry is found.

At 09:58 16/05/01, you wrote:
>John Holman wrote:
> >
> > As said before I'd like to add the ability to search the directory for the
> > user's dn to cover cases when a fixed pattern will not work, but will wait
> > to see the fate of this patch before going ahead.
>
>Regarding the "search, then bind" authentication; what would be the
>suggested behaviour when there are more than one returned dn from the
>search? Should one try to authenticate as each of these, or
>automatically assume not authenticated?
>
>--
>- Torgeir

RE: JNDI/LDAP realm

[John Holman]

At 13:49 16/05/01, Steve Downey wrote:
>As I understand it, you can rebind with different credentials, but you can't
>have more than one set of credentials on the same connection. That means
>either synchronizing on the ldap connection, and serializing login, or
>having multiple connections and parallelizing login.

That's my understanding too - and in fact the directory should abort any 
pending requests on a connection when a rebind occurs. But I think either 
synchronisation or multiple connections/contexts are needed anyway, even if 
a system account is used to bind to the directory and that the same 
credentials are used throughout.


>Now, this isn't a terrible issue if the code cleans up promptly when done
>authenticating, but it is a resource contention issue.
>
>If the code doesn't clean up promptly, and relies on finalization, then it
>will only fail under load. Usually in some horrible manner that will be
>difficult to trace back to the root cause.

Yes. The initial code makes no attempt at performance - it serialises all 
requests through a single directory context.

John



> > -Original Message-
> > From: John Holman [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, May 14, 2001 5:55 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: JNDI/LDAP realm
> >
> >
> >
> > - Original Message -
> > From: "Steve Downey" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, May 14, 2001 5:39 PM
> > Subject: RE: JNDI/LDAP realm
> >
> >
> > > The downside to binding with the supplied credentials is
> > that it chews up
> > a
> > > file descriptor. For light loads, it's not an issue. For
> > heavy loads, it
> > can
> > > be a big issue. If the app server binds administratively,
> > you can get by
> > > with two connections, one for reading and one for writing.
> > Or even one, if
> > > you're not replicating LDAP.
> >
> > According to the JNDI tutorial at least, Suns's provider for
> > LDAP v3 is
> > supposed to allow rebinding with a different principal.and
> > credentials while
> > keeping the same directory context and underlying network connection.
> > (Although  in practice it doesn't always seem to work quite
> > like that). So
> > it might be possible not to need additional file descriptors.
> > Also, note
> > that the LDAP connection is only needed for a brief period at
> > the beginning
> > of a session when the user first authenticates. Not that the
> > present code
> > attempts to be efficient about reusing directory contexts etc.
> >
> > But perhaps I misunderstand what you are saying.
> >
> > > All in all, making it configurable is probably a good idea.
> >
> > Agreed.
> >
> > >
> > > > -Original Message-
> > > > From: Ellen Lockhart [mailto:[EMAIL PROTECTED]]
> > > > Sent: Sunday, May 13, 2001 12:58 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: JNDI/LDAP realm
> > > >
> > > >
> > > > I preferred binding to the directory with supplied
> > > > credentials because it
> > > > allows the realm implementation to use an anonymous password
> > > > for the rest of
> > > > what it needs.
> > > >
> > > > To allow for DN's in the directory that may not be composed
> > > > of the same
> > > > attributes as other DN's, one thing I was thinking about
> > > > doing to the one I
> > > > submitted was to configure what the login attribute is (cn,
> > > > uid, etc.) and
> > > > search for it (with anonymous login) to get the dn, then
> > bind to the
> > > > directory with the resultant DN and the user-entered password to
> > > > authenticate.  This might be a little less efficient than
> > > > just searching and
> > > > getting the password as well, but is more secure than
> > having the root
> > > > password to the ldap server where it might be accessible
> > by someone.
> > > >
> > > >
> > > > - Original Message -
> > > > From: "John Holman" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Cc: <[EMAIL PROTECTED]>
> > > > Sent: Sunday, May 13, 2001 5:02 AM
> > > > Subject: JNDI/LDAP realm
> > > >
> > > >
> > > > > The current JNDI realm implementation in Tomcat 4 is
>

[PATCH] Catalina JNDIRealm - binding as the user

[John Holman]

Here is a patch for the JNDI  realm in Catalina that supports authentication
by binding to the directory with the credentials specified by the user.

I've added a configuration parameter "bindAsUser" which defaults to "true".
If set to "false" the realm authenticates as before: ie it retrieves the
password from the directory and compares it explicitly with the presented
credentials.

For the moment I've kept JNDIRealm as a single implementation class, but it
would be trivial to split it into different classes for the two modes of
authentication, if that is thought better. I've not updated the initial
javadoc comment because this will depend on whether the class is split or
not.

Note that digest authentication is not supported in the default "bind" mode.
Torgeir has suggested that this might be possible - if so that would be
good.

As said before I'd like to add the ability to search the directory for the
user's dn to cover cases when a fixed pattern will not work, but will wait
to see the fate of this patch before going ahead.

Cheers, John



Index: JNDIRealm.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
retrieving revision 1.1
diff -c -r1.1 JNDIRealm.java
*** JNDIRealm.java  2001/04/13 21:18:42 1.1
--- JNDIRealm.java  2001/05/15 21:17:46
***
*** 68,73 
--- 68,74 
  import javax.naming.NameNotFoundException;
  import javax.naming.NamingEnumeration;
  import javax.naming.NamingException;
+ import javax.naming.AuthenticationException;
  import javax.naming.directory.Attribute;
  import javax.naming.directory.Attributes;
  import javax.naming.directory.DirContext;
***
*** 238,243 
--- 239,250 
  
  
  /**
+  * Should we authenticate by binding to the directory as the user?
+  */
+ protected boolean bindAsUser = true;
+ 
+ 
+ /**
   * The attribute name used to retrieve the user password.
   */
  protected String userPassword[] = null;
***
*** 253,258 
--- 260,266 
  // - Properties
  
  
+ 
  /**
   * Return the connection username for this Realm.
   */
***
*** 342,347 
--- 350,377 
  
  
  /**
+  * Return the "bind as user" flag.
+  */
+ public boolean getBindAsUser() {
+ 
+ return (this.bindAsUser);
+ 
+ }
+ 
+ 
+ /**
+  * Set the "bind as user" flag.
+  *
+  * @param bindAsUser The new search flag
+  */
+ public void setBindAsUser(boolean bindAsUser) {
+ 
+ this.bindAsUser = bindAsUser;
+ 
+ }
+ 
+ 
+ /**
   * Return the base element for role searches.
   */
  public String getRoleBase() {
***
*** 581,586 
--- 611,766 
  
  
  /**
+  * Return the distinguished name of an authenticated user (if successful)
+  * or null if authentication is unsuccessful.
+  *
+  * @param context The directory context we are accessing
+  * @param username Username to be authenticated
+  * @param credentials Authentication credentials
+  *
+  * @exception NamingException if a directory server error occurs
+  */
+ protected String getUserDN(DirContext context,
+String username, String credentials)
+ throws NamingException {
+ 
+ if (debug >= 2)
+ log("getUserDN(" + username + ")");
+ 
+ if (username == null)
+ return (null);
+ 
+ if ((userFormat == null) || (userPassword == null))
+ return (null);
+ 
+ // substitute username into the pattern to get the dn
+ String dn = userFormat.format(new String[] { username });
+ if (debug >= 3)
+ log("  dn=" + dn);
+ 
+   boolean isAuthenticated = false;
+ if (bindAsUser)
+   isAuthenticated = bindAsUser(context, dn, credentials);
+   else
+   isAuthenticated = compareCredentials(context, dn, credentials);
+ 
+ if (isAuthenticated) {
+ if (debug >= 2)
+ log(sm.getString("jndiRealm.authenticateSuccess",
+  username));
+ } else {
+ if (debug >= 2)
+ log(sm.getString("jndiRealm.authenticateFailure",
+  username));
+ return (null);
+ }
+ 
+   return (dn);
+ }
+ 
+ 
+ /**
+  * Can we bind to the directory as the user?
+  *
+  * @param context The directory context we are accessing
+  * @param dn DN to bind as
+  * @param credentials Authentication credentials
+  *
+  * @exception NamingException if a directory server error occurs
+  */
+ protected boolean bindAsUser(DirContext context,
+String dn, String credentials)
+

Re: JNDI/LDAP realm

[John Holman]

- Original Message -
From: "Steve Downey" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 14, 2001 5:39 PM
Subject: RE: JNDI/LDAP realm


> The downside to binding with the supplied credentials is that it chews up
a
> file descriptor. For light loads, it's not an issue. For heavy loads, it
can
> be a big issue. If the app server binds administratively, you can get by
> with two connections, one for reading and one for writing. Or even one, if
> you're not replicating LDAP.

According to the JNDI tutorial at least, Suns's provider for LDAP v3 is
supposed to allow rebinding with a different principal.and credentials while
keeping the same directory context and underlying network connection.
(Although  in practice it doesn't always seem to work quite like that). So
it might be possible not to need additional file descriptors. Also, note
that the LDAP connection is only needed for a brief period at the beginning
of a session when the user first authenticates. Not that the present code
attempts to be efficient about reusing directory contexts etc.

But perhaps I misunderstand what you are saying.

> All in all, making it configurable is probably a good idea.

Agreed.

>
> > -Original Message-
> > From: Ellen Lockhart [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, May 13, 2001 12:58 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: JNDI/LDAP realm
> >
> >
> > I preferred binding to the directory with supplied
> > credentials because it
> > allows the realm implementation to use an anonymous password
> > for the rest of
> > what it needs.
> >
> > To allow for DN's in the directory that may not be composed
> > of the same
> > attributes as other DN's, one thing I was thinking about
> > doing to the one I
> > submitted was to configure what the login attribute is (cn,
> > uid, etc.) and
> > search for it (with anonymous login) to get the dn, then bind to the
> > directory with the resultant DN and the user-entered password to
> > authenticate.  This might be a little less efficient than
> > just searching and
> > getting the password as well, but is more secure than having the root
> > password to the ldap server where it might be accessible by someone.
> >
> >
> > - Original Message -
> > From: "John Holman" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Sunday, May 13, 2001 5:02 AM
> > Subject: JNDI/LDAP realm
> >
> >
> > > The current JNDI realm implementation in Tomcat 4 is based on code I
> > > submitted, which was subsequently modified and committed by Craig.
> > >
> > > Two significant changes he made are:
> > >
> > > - the original code found the DN of the user by searching
> > the directory.
> > The
> > > current implementation, like Ellen Lockhart's recent submission,
> > determines
> > > the DN by substituting the username into a string.
> > >
> > > - the original code supported a mode in which the user is
> > authenticated by
> > > binding to the directory with the supplied credentials (as
> > does Ellen's).
> > > The code for this was removed, with a comment in the commit
> > log that this
> > > mode should be supported probably in a separate
> > implementation class.
> > >
> > > I did comment on this in an earlier message, but got no
> > response - so I'm
> > > trying again now there is another little wave of interest :)
> > >
> > > Determining the DN. The pattern substitution method in the current
> > > implementation is obviously more efficient when applicable
> > but the search
> > > method is more general. For example, unlike the current
> > implementation,
> > > search can handle the following common use cases:
> > >
> > > - users are stored within multiple nodes in the directory
> > (e.g. they may
> > be
> > > held under different
> > > organisational units)
> > >
> > > - the attribute used in distinguished names is not the same
> > as that the
> > user
> > > enters into the basic authentication dialog box (e.g. the
> > user might enter
> > > mail address as the username rather than uid; the directory
> > might use
> > > commonName as a component of distinguished names rather than uid).
> > >
> > > So there are really two orthogonal issues for user
> > authentication each
> > with
> > > two options:
> 

Re: JNDI/LDAP realm

[John Holman]

> I preferred binding to the directory with supplied credentials because it
> allows the realm implementation to use an anonymous password for the rest
of
> what it needs.

Yes - I think binding is the better approach in general. Also the directory
can then contain password hashes rather than plaintext passwords without the
Tomcat realm having to know about the details. The only advantage I can see
for having the realm retrieve the password is that it makes http digest
authentication possible, provided that the plaintext password or a suitable
hash is stored in the directory. Whether any web browser actually supports
digest authentication is another matter ...

> To allow for DN's in the directory that may not be composed of the same
> attributes as other DN's, one thing I was thinking about doing to the one
I
> submitted was to configure what the login attribute is (cn, uid, etc.) and
> search for it (with anonymous login) to get the dn, then bind to the
> directory with the resultant DN and the user-entered password to
> authenticate.  This might be a little less efficient than just searching
and
> getting the password as well, but is more secure than having the root
> password to the ldap server where it might be accessible by someone.

That too is my preferred approach, and it's how the code I originally
submitted works.

JNDI/LDAP realm

[John Holman]

The current JNDI realm implementation in Tomcat 4 is based on code I
submitted, which was subsequently modified and committed by Craig.

Two significant changes he made are:

- the original code found the DN of the user by searching the directory. The
current implementation, like Ellen Lockhart's recent submission, determines
the DN by substituting the username into a string.

- the original code supported a mode in which the user is authenticated by
binding to the directory with the supplied credentials (as does Ellen's).
The code for this was removed, with a comment in the commit log that this
mode should be supported probably in a separate implementation class.

I did comment on this in an earlier message, but got no response - so I'm
trying again now there is another little wave of interest :)

Determining the DN. The pattern substitution method in the current
implementation is obviously more efficient when applicable but the search
method is more general. For example, unlike the current implementation,
search can handle the following common use cases:

- users are stored within multiple nodes in the directory (e.g. they may be
held under different
organisational units)

- the attribute used in distinguished names is not the same as that the user
enters into the basic authentication dialog box (e.g. the user might enter
mail address as the username rather than uid; the directory might use
commonName as a component of distinguished names rather than uid).

So there are really two orthogonal issues for user authentication each with
two options:

- how the dn for the user is determined (configuration template vs directory
search)
- how authentication is done (system login vs binding as the user)

I think it's important that Tomcat supports the missing combinations of
options. In fact, the most common strategy when using a directory for
authentication is probably "search then bind", neither component of which is
supported by the current implementation.  For example, this is the strategy
taken by pam_ldap and by the auth_ldap Apache module.

I'd be happy to have a go at adding the missing functionality, but would
like some feedback first as to whether people think this is a good idea.
Also opinions as to whether we should have one, two or even four classes to
implement the different combinations (with multiple classes maybe derived
from a base JNDIRealm class). We should take into account which variation is
likely to lead to the simplest and clearest configuration documentation ...

John.

JNDI realm

[John Holman]

The log of Craig's initial commit for JNDIRealm says:

> TODO:  Support an operational mode where the Realm attempts to bind to the
> directory server using the user's username and password (instead of a
> system administrator username and password).  This is a different enough
> style that it probably should be a separate implementation class.

In the initial commit it is assumed that the user dn can be expressed as a
pattern specified in the server.xml configuration in which the username is
substituted. This is an efficient approach when the assumption is justified,
but quite often it is not:

- users may be held in a tree in the directory (e.g. under different
organizational units)

- the attribute used for naming in distinguished names may not be the same
as that the user enters into the basic authentication dialog box (e.g. the
user might enter mail address as the username rather than uid; the directory
may use commonName in distinguished names rather than uid).

So I suggest we support a mode where the user's dn is found by a directory
search on the value of an arbitrary attribute. This "search then bind"
approach is taken by at least two two other popular applications: pam_ldap
and the auth_ldap module for Apache. Compatibility with the latter means
that people could always use the same directory data for access control to
static pages (via auth_ldap) and to dynamic ones (via Tomcat's JNDIRealm).

Thus there are really two orthogonal options for user authentication

- how the dn for the user is determined (configuration template vs directory
search)
- how the authentication is done (system vs user login)

I think we should support all four variations. Four implementation classes
are a possibility, and would avoid a little run-time overhead, but involves
some code duplication and configuration could be a little awkward to
describe. Another possibility is to implement within the same class, in
which case the processing done by getUserDN() will vary depending upon which
configuration properties are defined. For example, if property
"userDNFormat" is defined, the DN is formed by substituting the username
into a template; otherwise properties such as "userFilter", "userBase" and
"userSubtree" define a search for the DN (as in my original submission).
Similarly if "userPassword" is defined the system login approach is used;
otherwise authentication is done by binding as the user. Either way (or
indeed if we think it'd be better to have two implementation classes with
one option varying within the class) if there's interest I'd be willing to
have a go at it.

On a different but related topic,  I wonder whether it is sensible to assume
that user authentication and the determination of roles always use the same
mechanisms. For example one might want to use a directory service for
authentication but look up roles in a database - or vice versa. Obviously
supporting this would require significant refactoring to the Realm
implementation in general.

Finally I've looked (e.g. in the servlet spec) but can't find a clear
statement about what Principal.getName() should return. The current
implementation returns the username (ie same as getRemoteUser()). Might the
distinguished name be more appropriate when a directory service is used?

John.

Re: JNDI realm for Catalina

[John Holman]

- Original Message -
From: "Martin Smith" <[EMAIL PROTECTED]>


> I wonder if it wouldn't be useful to permit a principal or a credential to
be an
> attribute in the user's (subject's) own entry, e.g., "creditbalance." (For
some
> types of data, I wonder if it may be more efficient to maintain it
"distributed"
> in subjects' entries rather than in a possibly very large and dynamic
attribute
> list.)
>
> (Perhaps it's obvious, but I'll mention that I'm a bit uncertain about the
> distinction and appropriate practical uses of "principals" versus
"credentials".

My understanding - which may not be accurate! -  is that in the context of a
web application the "principal" is the entity on behalf of which a request
is processed, while "credentials" are data used to authenticate that
principal - i.e. to establish its identity. But here I think you are talking
about something different from either - i.e. an attribute of an (already
authenticated) user that is used to decide whether to authorise access to
some resource.

In principle you might be able do what you want using the current code by
setting roleSearchBase to where the users entries are held and setting
roleSearchFilter to e.g. (&(mail={0})(creditBalance > 1)). This assumes
that you can define a "creditBalance" attribute type with a syntax that
makes the inequality work as you expect. In practice I'm not sure this is
necessarily the best approach in this particular case - perhaps it would be
better to retrieve the credit balance and make the comparison explicitly in
the application. Remember also that the role, once established, persists for
the lifetime of the session.

In general though it is certainly possible to define roles implicitly in
terms of attributes held in the user entries, and the design does support
this.

> Does this model handle "dynamic" groups, by which I mean a reference to a
> method/algorythm/formula computed at runtime, like "member of
ou=myDepartment",
> or "person entries with creditbalance > 1" ?  I understand this can be
> achieved by referring to an attribute that stores a URI that includes an
LDAP
> query string.

I *think* this is pecular to the Netscape/iPlanet directory servers. It
seems that you store an LDAP search query in the form of an LDAP URL as the
value of a "memberURL" attribute in an entry with object class
"groupOfURLs". What's not clear to me is whether the directory server
automatically executes the query when you ask for the value of such an
attribute. (This would be an extension of the LDAP standard). If so, you
could just define roleSearchFilter to be (groupOfURL={1}), thus matching the
user's DN with the list of computed DNs.  But if the directory server just
returns the URL for the client to use, the model as it stands would not
handle it.

>
> In any case, this authenticator is a very exciting contribution.

Thanks! - but note that there are other offerings and this particular one
may not make it into the Catalina code.

John

Re: JNDI realm for Catalina

[John Holman]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>

>>  To authenticate the
> > user, the directory is first searched for an entry with an attribute
> > matching the given username. An attempt is then made to bind to the
> > directory using the name of that entry and the password.
> >
>
> This is the way that the old Netscape Enterprise Server did it's LDAP
> authentication.  I think we should support this mode, as well as a mode
> where the Realm binds with a system username/password and then looks up
> user and password elements in the same way that JDBCRealm gets them from
> the database.

"Search then bind" seems to be the most common approach (e.g. pam_ldap and
the ldap_auth Apache module both authenticate that way). Advantages are that
no priviledges are needed, so it works with an anonymous connection, and
that the directory server can keep arbitrary hashes of the password instead
of the plaintext password without the client having to be concerned. However
I agree we should support the mode where the Realm gets the plaintext
password from the directory server and compares it with the client's
offering.

Incidentally there is an issue about supporting Digest Access
Authentication. In general it cannot be assumed that the plaintext password
will be held in the directory - in fact things are somewhat more secure if
it isn't - but without the plaintext password it isn't (usually) possible
for a Realm to calculate a digest to compare with what the browser sends. In
this implementation the getPassword() method defined in RealmBase always
returns null, and Digest Authentication won't work. The same thing is true
of the JDBCRealm - and presumably Digest Authentication is broken there as
well.

> Note that I've also started refactoring the Realm stuff a little, so that
> things like the GenericPrincipal class can be reused by other Realm
> implementations.

The current implementation uses GenericPrincipal.

> > A role is represented in the directory by an entry with an attribute
whose
> > values identify the users with that role, and optionally with an
attribute
> > whose value is the name of the role. In an LDAP directory a role entry
might
> > have a uniqueMember or member attribute to hold the distinguished names
of
> > the users. However other attribute types could be used, and the values
could
> > be usernames instead of DNs. In the current implementation, all the
roles
> > associated with a user are retrieved when the user is first
authenticated
> > and then cached in the Principal object.
> >
>
> That's the way I would do it as well.  Tomcat will cache the Principal
> (assuming the app is using sessions, which is the usual case) so this
> information can be used later to answer isUserInRole() type questions.

In the interests of flexibility, should we also provide the option of
representing roles as values of an attribute within the user entry?

Also in the interests of flexibility, the Realm can now be configured with
general  filters for user and role searches:

userSearchFilter - the filter to use when searching for a user entry. {0}
will be replaced with the value of the username. Default: (uid={0})

roleSearchFilter - the filter to use when searching for a user's roles. {0}
will be replaced with the distinguished name of the user entry. {1} will be
replaced with the username. . Default: (|(uniqueMember={0})(member={0}))

The roleValueIsDN, roleMemberAttribute and userNameAttribute configuration
parameters are now redundant (though it might be worth keeping some of them
to simplify common cases).

Given that there are now at least two other offerings covering similar
ground, I'm really not sure how to proceed. So I've attached the current
code to this message - I hope that's acceptable. It seemed better to make it
available now than to carry on in isolation.

John.



 JNDIRealm.java

JNDI realm for Catalina

[John Holman]

One of the action items in the Catalina status document is a JNDI realm.
I've been working on this recently and wonder whether what I've done would
be useful to the project - though I'm not sure how best to get involved.
Incidentally, the status document lists James W as a volunteer for this
item. I sent James a message a few days ago asking about progress but
haven't received a response yet.

Anyway, this is what I've done/plan to do. The current implementation
follows the general pattern of the existing JDBCRealm. It is assumed that
user and role information is held in a directory server. To authenticate the
user, the directory is first searched for an entry with an attribute
matching the given username. An attempt is then made to bind to the
directory using the name of that entry and the password.

A role is represented in the directory by an entry with an attribute whose
values identify the users with that role, and optionally with an attribute
whose value is the name of the role. In an LDAP directory a role entry might
have a uniqueMember or member attribute to hold the distinguished names of
the users. However other attribute types could be used, and the values could
be usernames instead of DNs. In the current implementation, all the roles
associated with a user are retrieved when the user is first authenticated
and then cached in the Principal object.

To accommodate the different ways that user and role information can be
represented in the directory a number of configuration attributes are
needed - though fortunately most can have defaults. Here is a possible set:

connectionURL - the connection URL to be passed to the JNDI provider.
Usually this will be an LDAP URL specifying the hostname and port of the
directory server and optionally the name of the root naming context. This
attribute is required. Example: ldap://ldap.acme.com:389

contextFactory - the class name of the inital context factory to use.
Default: com.sun.jndi.ldap.LdapCtxFactory

userSearchBase - the name of the context (relative to the root context)
within which to search for users.
This attribute is required. Example: ou=people

userNameAttribute - the name of the attribute whose value will be matched to
the given username. Default: "uid"

userSearchSubtree - if true the subtree starting at userSearchBase will be
searched for a user with the given username. If false a one-level search is
performed. Default: "false"

roleSearchBase - the name of the context (relative to the root context)
within which to search for roles. This attribute is required. Example:
ou=groups

roleMemberAttribute - the name of the attribute whose values identify the
users with that role. Default: uniqueMember.

roleNameAttribute - the name of the attribute whose value is the name of the
role. If not specifed, a role name is constructed from the leftmost
component of the name of the directory entry. (This will probably only work
for LDAP-style distinguished names).

roleSearchSubtree - if "true" the whole subtree starting at roleSearchBase
is searched for roles. If "false" a one-level search is performed. Default:
"false"

roleValueIsDN - if "true" the values of the roleNameAttribute are the
distinguished names of the users. If "false" they are usernames. Default:
"true" [ not yet implemented - only DNs handled ]

useSSL - whether to make an SSL connection to the directory server. Default:
"false". [not yet implemented]

connectionName - the dn to use when connecting to the directory server. If
not specified an anonymous connection is used.  [ not yet implemented ]

connectionPassword - the password to use when connecting to the directory
server. If not specified an anonymous connection is used. [ not yet
implemented ]

I'd welcome any feedback.

John.

Proposed release of 3.3

[John Holman]

I'm a user and I rightly don't get a vote 
(and might do better to keep quiet!) but I think releasing a version 3.3 would be bad for the project unless the 
concerns about support can be fully resolved. This is so even though it seems to be agreed that the basic code itself 
is technically superior to 3.2 (cleaner and more maintainable, better 
performance etc) and even if the new bugs it introduces are fixed.
 
The danger, it seems to me, is that many of 
those actively supporting 3.2 at the moment would prefer the project to move on 
to 4.x and will not be keen on supporting a 3.3, while 
those wanting a version 3.3 are focussed more upon program design and 
writing new code than bug fixes and user support.  Releasing a 3.3 will inevitably cause some users who would otherwise have 
moved on to 4.x to adopt it believing it to be the most "stable" version. But if 
it isn't properly supported, that will be far from the case, and will cause 
problems for users and the project alike.
 
John.