DO NOT REPLY [Bug 9700] New: - JNDIRealm authentication incorrectly succeeds with blank password

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9700>.
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=9700

JNDIRealm authentication incorrectly succeeds with blank password

           Summary: JNDIRealm authentication incorrectly succeeds with blank
                    password
           Product: Tomcat 4
           Version: 4.1.3
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: jemiller@uchicago.edu


I found that if you configure Tomcat to use JNDIRealm in the configuration 
where it binds as the remote user to the LDAP server (i.e. if you leave the 
userPassword attribute blank as described under bullet point 4 in the 
JNDIRealm documentation in the Catalina documentation), that it allows users 
to authenticate successfully with a blank password.

I think this is because LDAP considers authentication with a valid DN and a 
blank password an anonymous authentication. i.e. authentication doesn't fail, 
it just logs you in anonymously instead.

So, I'm thinking that JNDIRealm should probably check to make sure that 
password isn't blank and if it is a blank password, it should fail.

I'm using the following configuration in my server.xml.

<Realm className="org.apache.catalina.realm.JNDIRealm"
	debug="99"
	connectionName="cn=Manager, dc=mydomain"
	connectionPassword="mypassword"
	connectionURL="ldap://myldapserver"
	roleBase="ou=roles, dc=mydomain"
	roleName="cn"
	roleSearch="(uniqueMember={0})"
	roleSubtree="false"
	userPattern="uid={0}, ou=People, dc=mydomain"/>

I've tested this with OpenLDAP and iPlanet Directory Server and the behavior 
is the same.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>