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]>