2

I need to SECURELY externalize a username and password for a Spring application context used by some integration tests (for my application itself, I use JNDI).

The idea is like this:

application.properties application/

Then my spring application context datasource bean would look something like this:

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url" value="jdbc:mysql://localhost/my_database" />
    <property name="username" value="${application.username}" />
    <property name="password" value="${application.password}" />
    <property name="initialSize" value="3" />
    <property name="maxActive" value="10" />
  </bean>

The trick is that in the .properties file, the password must be encypted as well.

I have no idea if this is even possible, but maybe someone has an idea?

Jason

Ken Bekov
  • 13,696
  • 3
  • 36
  • 44
Jason
  • 3,943
  • 12
  • 64
  • 104
  • Use environment variables instead. Thus, the password is visible neither in application context file nor in properties file. – Thomas Lehoux Feb 01 '17 at 12:59
  • To be clear, a non-encrypted password cannot be stored ANYWHERE on my machine, due to a bunch of overzealous security types. – Jason Feb 01 '17 at 13:03
  • http://stackoverflow.com/questions/3423135/how-to-use-encrypted-password-in-apache-basicdatasource – Thomas Lehoux Feb 01 '17 at 13:11

1 Answers1

2

Define the datasource programmatically rather than in XML, or if you are using Spring Boot, by configuration in application.yaml

Either way specify the user and password as Spring Environment properties, and populate the properties from Spring Cloud Config server, which supports full encryption and decryption of sensitive properties.

See here

Alternatively if you're using an app server use a JNDI datasource and let the app server handle the datasource password security.

PaulNUK
  • 4,774
  • 2
  • 30
  • 58
  • 1
    I wanted to use JNDI to get the datasource, but I would have had to include the whole wlclient.jar in order to set the naming factory. Since I wanted the unit tests to "just work" without obnoxious configuration, I had to go another route. – Jason Feb 01 '17 at 14:57