Encrypted properties are needed for information that needs to be secured instead of exposing it as clear text. For data sources, that's generally for security credentials like passwords. Since the first release, WLS data source has only supported a single encrypted property, the database password corresponding to the database user for all connections on the data source. That was fine for simple security but adding features like SSL needed additional passwords for the key store and trust store. We figured out a limited solution by using the Oracle auto-login wallet with store type SSO that did not require an additional password value. That's documented at http://docs.oracle.com/middleware/1213/wls/JDBCA/ds_security.htm#CHDBBIJH .
We explored options for supporting additional encrypted properties including encrypting all properties with the name "Password" but it didn't seem to be an elegant solution. In 10.3.6, we made a simple extension to connection properties to support system properties. In WLS 12.1.3, we made a similar extension to support encrypted properties. A JDBC property now consists of a name and a choice of a value, a system property value, or an encrypted value. Encrypted values would commonly be used for javax.net.ssl.trustStorePassword and/or javax.net.ssl.keyStorePassword when configuring SSL.
You can set the encrypted property in a WLST script using
The clear text value (literal or variable) is encrypted and then stored as an encrypted value in the descriptor. This works for both on-line and off-line WLST. If you have an on-line WLST script, you can also use
In this case, the encryption is automatically done and the encrypted value is stored.
You can also use the WLS administration console to create encrypted properties. It's not possible to specify the encrypted values when creating a data source. That is, the creation assistant doesn't support encrypted properties. When you create a data source, you might need to put in a clear-text password if you want to test the connection during the creation process. You can add encrypted values to the data source definition by editing the configuration. You need to go to the Configuration Connection Pool tab (the same tab as normal properties and system properties). If you used clear-text passwords during creation for testing, you will need to remove the clear text values first. There are two approaches to add encrypted values. One is to type the name and clear text value directly into the Encrypted Properties text box. When you click on the Save button, the values are encrypted. The advantage of this approach is that you can enter multiple values directly but the downside is that between the text entry and saving the values, the values are visible on the screen. This approach is shown in the following figure.
There is a second approach that provides secure data entry. Note in the picture above, there is an "Add Securely" button to the right of the Encrypted Properties text box. Clicking on that button causes a new window to pop up as in the following figure. You can enter the property name and then the encrypted value twice. The input for the encrypted values is obscured. When done, click on the OK button to enter the name and encrypted value in the Encrypted Properties text box. The advantage of this approach is that the clear text value is never displayed.
You can see the product documentation for encrypted properties at http://docs.oracle.com/middleware/1213/wls/JDBCA/ds_security.htm#CHDGCDIB, including some code examples.
The timing was good for this feature because a lot of testing was done on setting up one-way and two-way SSL configurations in the Server for WLS 12.1.3. See http://docs.oracle.com/middleware/1213/core/ASADM/sslconfig.htm#CBDFGCAF for a discussion of using SSL with the data tier. This release also introduced FIPS 140 support in Oracle Fusion Middleware. See http://docs.oracle.com/middleware/1213/core/ASADM/fips.htm for more details.
WLS 12.1.3 has a complete SSL security solution that is well tested and well documented. Support for encrypted data source connection properties is one important piece in the solution.
P.S. Earlier versions of the documentation said "You must enable the Oracle PKI provider. This can either be done statically by updating the
java.security file under the JRE or dynamically by setting it in a WLS startup class ...". Updating the JRE java.security file was removed from the documentation in WLS 12.1.3 because testing found that it didn't work for two-way SSL. A bug was fixed in the oraclepki.jar file late in 12.1.3 and this approach now works. It may be the easier of the two approaches.