This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hello all, I want to use Tomcat's server.xml to store the password to my database which is used by a webapp. The database does not store information about tomcat users so it's not for authentication. The main purpose of this is I cannot have a plain text password stored in my Java code on the server. So I need to store the hashed password somewhere in the Tomcat configuration using digest and ask for a connection from the container itself. I understand that if Tomcat is to make the connection it needs to know how to decrypt the password, and if someone gained access to the server they could easily get the password... but these are the requirements. Does anyone have an example or could point me to an example of how to do this? I've read through: http://ci.apache.org/projects/tomcat/tomcat6/docs/realm-howto.html and it seems like the only purpose is for user authentication.
Realms are solely for user authentication and authorization, that is correct. They have no relationship at all with application data access, and in fact, most of the Realms don't even expect to be backed by databases; realms using XML files, LDAP servers, JAAS, network-based services, and other non-DBMS-based realms are all in common use.
Databases should normally be accessed via pooled connections. When you use a pool, the connections (which require a database userid and password to create) are supplied externally, and therefore the web application has absolutely no business having either database userids OR database passwords embedded within it.
When you configure a database connection pool, you provide it with 4 primary parameters:
1. The connection URL
2. The driver class to use
3. The userId used to obtain all pool connections
4. The password corresponding to that userId.
These elements are normally supplied in clear text, since the pool definition is done in a secured location where it doesn't really matter whether the credentials are encrypted or not. If someone has access to the pool definition, they already pretty much own the system anyway.
It's generally good practice to assign a unique set of security credentials solely to connection pool in order to be able to restrict what the webapp(s) can do using that account. Although that doesn't mean that the apps can get careless, since the access rules will have to be the greatest-common-denominator of all the webapp users using connections from that pool.
An IDE is no substitute for an Intelligent Developer.