Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 92003 invoked from network); 12 Jan 2003 19:30:55 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 12 Jan 2003 19:30:55 -0000 Received: (qmail 26471 invoked by uid 97); 12 Jan 2003 19:31:55 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 26391 invoked by uid 97); 12 Jan 2003 19:31:54 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 26353 invoked by uid 98); 12 Jan 2003 19:31:52 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) From: "Rob Abernethy IV" To: "Tomcat Users List" Subject: Re: JDBCRealm Date: Sun, 12 Jan 2003 14:30:22 +0800 Message-Id: <20030112143022.M79668@dynedge.com> In-Reply-To: <20030110162621.M4091@dynedge.com> References: <20030102131238.M71858@dynedge.com> <000601c2b2a2$955cfae0$6a6fb6d1@tbird.com> <20030102182011.M79277@dynedge.com> <019001c2b2db$4e559a10$6a6fb6d1@tbird.com> <20030103132116.M85672@dynedge.com> <006301c2b5c6$ec5794f0$6a6fb6d1@tbird.com> <20030107165357.M65171@dynedge.com> <20030108002503.GA4742@idoru.tenten> <001f01c2b6ca$2cbd2ec0$6a6fb6d1@tbird.com> <20030108114849.M48528@dynedge.com> <017001c2b793$0fc63a40$6a6fb6d1@tbird.com> <20030109121945.M59218@dynedge.com> <20030110162621.M4091@dynedge.com> X-Mailer: Open WebMail 1.64 20020419 X-OriginatingIP: 24.208.224.236 (abernethy@dynedge.com) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Alright, I finally have my answer. Postgres prepends the username to the password before creating the digest. For example, if I wish to create a postgres account with the username 'tomcat' and password 'tomcat', postgres will prepend 'tomcat' to 'tomcat' to create 'tomcattomcat' and then make the digest. Unfortunately, I don't think there is any way to tell postgres *not* to use a salt when creating the encrypted version of the password. -- Robert Abernethy IV Dynamic Edge, Inc. 734.975.0460 > Ok, I got Java and Perl to come up with the same digest. Postgres' > is different. I think it has something to do with the 'salt'. > Postgres uses the username as salt. I don't know much about MD5 > encryption, but it seems as though Java is using a different salt > and, therefore, coming up with a different digest. > > -- > Robert Abernethy IV > Dynamic Edge, Inc. > 734.975.0460 > > > Clear-text password: tomcat > > > > java org.apache.catalina.RealmBase -a MD5 tomcat > > 1b359d8753858b55befa0441067aaed3 > > > > select passwd from pg_shadow where usename='tomcat' > > md5efcc1c51a80be13b59cdb96d758a0184 > > > > md5sum -t < tomcat > > 042d39e062dd4bf342e088dc832526f9 > > > > String password = "tomcat"; > > byte[] md_password = password.getBytes(); > > MessageDigest md = MessageDigest.getInstance("MD5"); > > byte[] md_hash = md.digest(md_password); > > System.out.println(md_hash); > > [B@15f5897 > > > > So obviously the authentication is failing because the MD5'd > > passwords don't match. Tomcat is calculating the digest using the > > RealmBase and the digest stored in the table was created by > > Postgres. Is there a reason why these are all different? > > > > -- > > Robert Abernethy IV > > Dynamic Edge, Inc. > > 734.975.0460 > > > > > ----- Original Message ----- > > > > > > > The MD5'd password *is* in the pg_shadow.passwd column. I don't see > what > > > > I'm doing wrong. > > > > > > Is Postgres (or anything other than Java) generating the MD5'd > > > passwords for the pg_shadow table? If so, have you manually > > > generated the MD5's to see if they are the same? > > > > > > Even if they are you can run into problems with storage formats. If > > > Postgres is using a different char set than the Java JVM for manipulating > > > the strings, you can have mismatches. > > > > > > Also, if you use CHAR instead of VARCHAR you may have extra spaces > > > stuck on the end of the returned string to pad it out. > > > > > > The MD5 is longer than the string it is generated from so you need > > > to make sure you have plenty of room for it. > > > > > > For example if Java is using UTF-8 and Postgres is using Win1251, > > > the same character can be represented by different numbers. You > > > usually see this with special or non-english characters. Your web > > > app stores a string in the database, then you look at it with a > > > database with a browsing tool and some characters are different or > > > get returned as ???. > > > > > > This can play hell with MD5 calculations. > > > > > > > And, as far as confusing postgres users with tomcat users, > > > > is there a problem with using the same user for both? I kind of thought > > > > that was the point. When I create a user, they can use the same > username > > > > and password to access tomcat web apps that they use to connect to the > > > > database. > > > > > > That only works if you wait to define connections inside your web > > > app. This severely limits the effectiveness of connection pools. > > > > > > That chews up huge amounts of resources in a web app used by lots of > > > users because building and tearing down connections uses a lot of > > > cycles and memory. > > > > > > Even if you pool in your web app each user will have their own pool > > > and at least one real connection will have to be opened for each user. > > > > > > You can get around this on some databases if they let you set the > > > role or the user on an open connection. That is very non-standard > > > and could cause problems if you switch databases. > > > > > > All users of a web app usually share the same database > > > username/password in a connection pooled environment where you are > > > using a dataSource. It gets locked in at the time the dataSource is > > > set up. So all users of the web app have the same read, update, > > > select privleges. If you want to restrict that on a per user basis > > > you have to enforce that in your web app, usually using Tomcat Roles. > > > > > > A Tomcat Role differs from a database Role, so you have to be > > > careful there. You may or may not have access to the databases user > > > Role table depending on the database. The problem is that if your > > > dataSource belongs to user "tomcat" and user "Joe" logs into the web > > > app the database may not let tomcat look at Joe's database Roles for > > > security reasons. > > > > > > > > > > > Thanks for the pointers on security. Both Tomcat and Postgres are on > the > > > > same server. I'm also planning on using HTTPS, but apache will handle > > > that > > > > part. I think it will work something like this: > > > > > > > > 1. user types username and password (clear-text) into form > > > > 2. web browser encrypts everything and sends it to web server (https) > > > > 3. apache decrypts everything and passes it onto tomcat > > > > 4. tomcat makes a MD5 form of the given password > > > > 5. tomcat compares this with the MD5 password taken from the database > > > > > > > > Does that sound right? > > > > > > Yes, with the caveats above. Good Luck! > > > > > > Rick > > > > > > > > > > > -- > > > > Robert Abernethy IV > > > > Dynamic Edge, Inc. > > > > 734.975.0460 > > > > > > > > > Yeah, looks like you almost have it. The MD5'd password should be in > > > > > pg_shadow in the userCredCol, passwd in this case. > > > > > > > > > > Be advised that you should either use only HTTPS for this, or run > > > > > Tomcat on the same server as Postgres, or run them both on a secure > > > > > net behind a firewall on separate machines to prevent your Postgres > > > > > database from being compromised. > > > > > > > > > > MD5 really only prevents snoops on your server from being able to > easily > > > > > read the passwords in pg_shadow. > > > > > > > > > > Rick > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > * Rob Abernethy IV [0154 21:54]: > > > > > > > OK. I was able to get clear-text passwords to work, but I still > > > can't > > > > > get > > > > > > > encrypted passwords to work. Using MD5 encryption, Tomcat is able > > > to > > > > > > > successfully open a connection to the database using the JDBCRealm > > > set > > > > > up in > > > > > > > the server.xml, but it is unable to authenticate users for the > admin > > > > web > > > > > app. > > > > > > > I am using the same username and password (username = "tomcat", > > > > > password = > > > > > > > "tomcat") for both the JDBCRealm and the admin web app. > > > > > > > > > > > > > > JDBCRealm: > > > > > > > > > > > > > driverName="org.postgresql.Driver" > > > > > > > connectionURL="jdbc:postgresql://bilbo.dynedge.com/template1" > > > > > > > connectionName="abernethy" connectionPassword="gceIlu4DaR" > > > > > > > userTable="pg_shadow" userNameCol="usename" > > > > userCredCol="passwd" > > > > > > > userRoleTable="pg_groupview" roleNameCol="groname" > > > > > > > digest="MD5" /> > > > > > > > pg_shadow: > > > > > > > usename | passwd > > > > > > > ------------------------- > > > > > > > tomcat | md5efcc1c51a80be13b59cdb96d758a0184 > > > > > > > > > > > > You are confusing postgres usernames/passwords with the ones you > want > > > in > > > > > the tables. > > > > > > Tomcat connects to the database as user connectionName , password > > > > > connectionPassword > > > > > > > > > > > > and looks up http authentication users and passwords in userTable > and > > > > > userRoleTable. > > > > > > > > > > > > It looks from your post like you have that backwards (pg_shadow > holds > > > > > postgres users, not users > > > > > > for your apps). > > > > > > > > > > > > > postgresql log (for admin web app authentication): > > > > > > > Jan 7 16:43:34 bilbo postgres[4329]: [9] LOG: query: SELECT > passwd > > > > > FROM > > > > > > > pg_shadow WHERE usename = 'tomcat' > > > > > > > Jan 7 16:43:34 bilbo postgres[4329]: [10] LOG: duration: > 0.001636 > > > sec > > > > > > > > > > > > > > catalina_log.2003-01-07.txt: > > > > > > > 2003-01-07 16:43:34 JDBCRealm[Standalone]: Username tomcat NOT > > > > > successfully > > > > > > > authenticated > > > > > > > > > > > > -- > > > > > > Rasputin :: Jack of All Trades - Master of Nuns > > > > > > > > > > > -- > > > To unsubscribe, e-mail: unsubscribe@jakarta.apache.org> > > > For additional commands, e-mail: help@jakarta.apache.org> > > > > -- > > To unsubscribe, e-mail: unsubscribe@jakarta.apache.org> > > For additional commands, e-mail: help@jakarta.apache.org> > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: