tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Abernethy IV" <aberne...@dynedge.com>
Subject Re: JDBCRealm
Date Thu, 09 Jan 2003 04:19:45 GMT
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 <abernethy@dynedge.com> [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:
> > > > > <Realm  className="org.apache.catalina.realm.JDBCRealm" debug="99"
> > > > >        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:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message