Here's the link to the JNDIRealm doc in the Catalina documentation. The main Realm how-to doc hasn't been updated yet.
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/catalina/docs/api/org/apache /catalina/realm/JNDIRealm.html I think the userSearch attribute is the one that you need to use. Jon ----- Original Message ----- From: "John Holman" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Friday, June 21, 2002 6:52 PM Subject: Re: JNDIRealm in v4.1 > 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: <mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
