Hi Felix, First thanks for your reply.
On Tue, Oct 7, 2014 at 6:35 PM, Felix Schumacher < felix.schumac...@internetallee.de> wrote: > Hi Igor, > > Am 07.10.2014 07:07, schrieb Igor Cicimov: > >> Hi all, >> >> I've been setting up user authentication based on JNDIRealm and have >> couple >> of questions regarding the operation. I've been using one of the secured >> applications that come with the examples included in Tomcat source for >> testing. My setup with obfuscated names and passwords is as follows. >> > Which tomcat version do you use? > It's 7.0.52-1ubuntu0.1 from Ubuntu 14.04 repository, sorry I missed mentioning that. > >> I have the following Realm in the default host: >> >> <Host name="localhost" appBase="webapps" unpackWARs="true" >> autoDeploy="false"> >> <Realm className="org.apache.catalina.realm.JNDIRealm" >> debug="99" >> > debug is not used anymore, so just delete it. > Done. > > connectionURL="ldap://ldap1.mydomain.com:389"; >> alternateURL="ldap://ldap2.mydomain.com:389"; >> connectionName="cn=connect,ou=Users,dc=mydomain,dc=com" >> connectionPassword="password" >> userBase="ou=Users,dc=mydomain,dc=com" >> userSearch="uid={0}" >> roleBase="ou=Groups,dc=mydomain,dc=com" >> roleName="cn" >> roleSearch="memberUid={1}" >> >> contextFactory="org.apache.catalina.ldap.realm.LdapTlsContextFactory"/> >> > Do you need the LdapTlsContextFactory? If so, what is your ldap server > setup? > Good that you mentioned that I wanted to ask about this in a separate thread. I was searching for STARTTLS support in the JNDIRealm and this was the only solution I could find. I got the directions from here: http://wiki.apache.org/tomcat/JNDI_startTLs_HowTo, so I compiled and installed the context factory since the TLS is a must fro my user case. It's working fine for me but still wanted to ask, since the above HowTo is from 2010, has this been maybe integrated in the Tomcat mainstream now and I have missed something in the documentation or is it still a (only) valid solution for TLS support? > > ... >> </Host> >> >> and have modified the security constraint roles in the web.xml of the >> examples application to match my LDAP groups: >> >> <auth-constraint> >> <!-- Anyone with one of the listed roles may access this area --> >> <!--<role-name>tomcat</role-name>--> >> <!--<role-name>role1</role-name>--> >> <role-name>MyCompany Users</role-name> >> <!--<role-name>tomcat-users</role-name>--> >> </auth-constraint> >> ... >> <security-role> >> <role-name>tomcat-users</role-name> >> </security-role> >> <security-role> >> <role-name>MyCompany Users</role-name> >> </security-role> >> >> Now when I hit the protected application, >> https://myserver/examples/jsp/security/protected/, I can successfully >> login >> but only if the role-name is set to "MyCompany Users". When I replace it >> with the tomcat-users, comment it out and uncomment the tomcat-users role >> name, the authentication fails. The following are the traces from the >> Tomcat log and LDAP log: >> > As you are finding below, the realm will only use one rolename from each > group it found. > Good to have that confirmed, thanks. > > Do you have a real usecase for setting more than one name in a group? > No, not really so shouldn't be a problem to remove the extra ones. > > If you only want to alias a role to another name, you could try adding > security-role-ref > links to your web.xml. > Good point. > > If you can modify the ldap values, you could use user-attributes to > specify roles. > Was also considering that but using the groups for role reference seamed simpler ie did not require any changes in LDAP. Simpler before I realised the cn problem which will need LDAP changes to get resolved so I might reconsider putting the role(s) in user attributes after all. Cheers, Igor > > Regards > Felix > > > >> Oct 07, 2014 2:35:06 PM org.apache.catalina.realm.RealmBase hasRole >> FINE: Username user1 does NOT have role tomcat-users >> Oct 07, 2014 2:35:06 PM org.apache.catalina.realm.RealmBase >> hasResourcePermission >> FINE: No role found: tomcat-users >> >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=1 BIND >> dn="cn=connect,ou=Users,dc=mydomain,dc=com" method=128 >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=1 BIND >> dn="cn=connect,ou=Users,dc=mydomain,dc=com" mech=SIMPLE ssf=0 >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=1 RESULT tag=97 err=0 >> text= >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=2 SRCH >> base="ou=Users,dc=mydomain,dc=com" scope=1 deref=3 filter="(uid=user1)" >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=2 SRCH attr=1.1 >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=2 SEARCH RESULT tag=101 >> err=0 nentries=1 text= >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=3 BIND anonymous >> mech=implicit ssf=0 >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=3 BIND >> dn="uid=user1,ou=Users,dc=mydomain,dc=com" method=128 >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=3 BIND >> dn="uid=user1,ou=Users,dc=mydomain,dc=com" mech=SIMPLE ssf=0 >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=3 RESULT tag=97 err=0 >> text= >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=4 SRCH base="" scope=0 >> deref=3 filter="(objectClass=*)" >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=4 SEARCH RESULT tag=101 >> err=0 nentries=1 text= >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=5 BIND anonymous >> mech=implicit ssf=0 >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=5 BIND >> dn="cn=connect,ou=Users,dc=mydomain,dc=com" method=128 >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=5 BIND >> dn="cn=connect,ou=Users,dc=mydomain,dc=com" mech=SIMPLE ssf=0 >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=5 RESULT tag=97 err=0 >> text= >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=6 SRCH >> base="ou=Groups,dc=mydomain,dc=com" scope=1 deref=3 >> filter="(memberUid=user1)" >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=6 SRCH attr=cn >> Oct 7 14:35:06 ldap1 slapd[1367]: conn=1123 op=6 SEARCH RESULT tag=101 >> err=0 nentries=2 text= >> >> So the LDAP server returns 2 entries for the role query (filtering by >> attr=cn) which can be confirmed by the following LDAP command doing the >> same: >> >> $ ldapsearch -LLL -Z -H ldap://myldap:389/ -D >> "cn=connect,ou=Users,dc=mydomain,dc=com" -W -b >> ou=Groups,dc=mydomain,dc=com >> "(memberUid=user1)" cn >> Enter LDAP Password: >> dn: cn=tomcat-users,ou=Groups,dc=mydomain,dc=com >> cn: MyCompany Users >> cn: tomcat-users >> >> dn: cn=user1,ou=Groups,dc=mydomain,dc=com >> cn: MyCompany Users >> cn: user1 >> >> >> Not sure if understand it correctly, but I thought the Realm would loop >> through the cn's returned and find the right one before it fails but looks >> like it picks up the first cn only? Is there something I can modify in my >> Realm without changing anything on the LDAP side to fix this? >> >> Thanks, >> Igor >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
