Thank you for responding John, John Holman wrote:
> Providing a connectionName and connectionPassword does *not* cause > JNDIRealm to lookup the password. It will still authenticate by > binding as the user unless you specify the userPassword configuration > attribute. I'm working with documentation for tomcat 4.0.4. It doesn't state any of this information. I did look at the information in the documentation for 4.1 and it is there. Thank you. I believe (through experimentation) that the 4.0.4 version of this does switch over to the "connectionUser/connectionPassword" at least for the role query, this because when I added them to my connection to a non-anonymous LDAP server, it started returning the roles without the presence of the userPassword attribute. > > Looking up roles as the administrator (or anonymously if > connectionName and connectionPassword are not specified) is a > deliberate design decision. > > John. ?? But, if you've already established a connection with the users principle and credentials, why would ever want to convert to a diferent set of principle/credentials to do the role lookup as a *rule*? This seems to be a *configuration* decision. It would be benifical if the interface provided for this option by providing something like a "bind-as-user='true|false'" "query-as-user='true|false'" in the realm configuration. This is a great Realm interface to JNDI/LDAP. Thanks for writting it. -Mark > > > Mark R. Diggory wrote: > >> Looking over the JNDIRealm Code I notice that in the bindAsUser >> method that the users principle and credentials are stripped out of >> the context. It is after this point that the JNDI search request is >> made to gather the roles from the ldap server. Shouldn't it be >> *after* the search for the roles that the users principle and >> credentials is removed from the DirContext? > > >> >> >> This would mean that I can never *really* use bindAsUser(...) >> strategy because I'd always have to provide a connectionUser and >> connectionPassword to do the role lookup. Not good at all. This means >> the configuration is impossible because if you provide the >> connectionName and connectionPassword attributes, then it just looks >> up the password on authentication instead of binding as the user. > > > > >> >> >> -M. >> >> Mark R. Diggory wrote: >> >>> I know my request should work at the LDAP Server through JNDI >>> because the following does work when I make a request to the LDAP >>> server. I do get back the groups. >>> >>> <% >>> Hashtable env = new Hashtable(); >>> env.put(DirContext.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory"); >>> >>> env.put(DirContext.SECURITY_PRINCIPAL,"uid=jadmin,ou=vdcid,ou=hmdc,o=vdc"); >>> >>> env.put(DirContext.SECURITY_CREDENTIALS,"******"); >>> env.put(DirContext.PROVIDER_URL,"ldap://vdc.fas.harvard.edu:389";); >>> >>> DirContext ctx = new InitialDirContext(env); >>> >>> SearchControls controls = new SearchControls(); >>> controls.setSearchScope(SearchControls.SUBTREE_SCOPE); >>> controls.setReturningAttributes(new String[] {"vdcGroup"}); >>> >>> NamingEnumeration enum = >>> ctx.search("o=vdc","(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)",controls); >>> >>> while(enum.hasMore()){ >>> SearchResult sr = (SearchResult)enum.next(); >>> out.print(sr.getAttributes().get("vdcGroup") + "<BR>"); >>> } >>> %> >>> >>> is returning >>> vdcGroup: public >>> vdcGroup: researchers >>> vdcGroup: curators >>> vdcGroup: administrators >>> >>> -Mark >>> >>> Mark R. Diggory wrote: >>> >>>> I'm trying to get a realm set up via JNDI to an Openldap server. >>>> Here is my current server.xml config. >>>> >>>> <Realm >>>> className="org.apache.catalina.realm.JNDIRealm" debug="99" >>>> connectionURL="ldap://vdc.fas.harvard.edu:389"; >>>> userPattern="uid={0},ou=vdcid,ou=hmdc,o=vdc" >>>> roleBase="o=vdc" >>>> roleSubtree="true" >>>> roleName="vdcGroup" >>>> roleSearch="(member={0})" >>>> digest="SHA" >>>> /> >>>> >>>> I'm using "vdcGroup" entries to store unique member attributes >>>> named 'member'. I can do this search using straight JNDI in a Test >>>> Java Application. But the realm will not return the vdcGroups that >>>> jadmin is a member of. Is there something obvious I am missing? >>>> >>>> -Mark >>>> >>>> 2002-09-07 10:40:51 JNDIRealm[Standalone]: Connecting to URL >>>> ldap://vdc.fas.harvard.edu:389 >>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: lookupUser(jadmin) >>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: >>>> dn=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc >>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: validating credentials >>>> by binding as the user >>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: binding as >>>> uid=jadmin,ou=vdcid,ou=hmdc,o=vdc >>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Username jadmin >>>> successfully authenticated >>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: >>>> getRoles(uid=jadmin,ou=vdcid,ou=hmdc,o=vdc) >>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Searching role base >>>> 'o=vdc' for attribute 'vdcGroup' >>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: With filter expression >>>> '(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)' >>>> 2002-09-07 10:41:11 JNDIRealm[Standalone]: Returning 0 roles >>>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT >>>> have role tomcat >>>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT >>>> have role role1 >>>> 2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT >>>> have role administrators >>>> >>>> >>>> -- >>>> 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]> >> > > > -- > 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]>
