I’ve written a couple of articles on how to store data source security credentials using the Oracle wallet. I plan to write a few articles on the various types of security available to WebLogic Server (WLS) data sources. There are more options than you might think!
There have been several enhancements in this area in WLS 10.3.6. There are a couple of more enhancements planned for release WLS 12.1.2 that I will include here for completeness. This isn’t intended as a teaser. If you call your Oracle support person, you can get them now as minor patches to WLS 10.3.6.
The current security documentation is scattered in a few places, has a few incorrect statements, and is missing a few topics. It also seems that the knowledge of how to apply some of these features isn’t written down. The goal of these articles is to talk about WLS data source security in a unified way and to introduce some approaches to using the available features.
Introduction to WebLogic Data Source Security Options
By default, you define a single database user and password for a data source. You can store it in the data source descriptor or make use of the Oracle wallet. This is a very simple and efficient approach to security. All of the connections in the connection pool are owned by this user and there is no special processing when a connection is given out. That is, it’s a homogeneous connection pool and any request can get any connection from a security perspective (there are other aspects like affinity). Regardless of the end user of the application, all connections in the pool use the same security credentials to access the DBMS. No additional information is needed when you get a connection because it’s all available from the data source descriptor (or wallet).
java.sql.Connection conn = mydatasource.getConnection();
Note: You can enter the password as a name-value pair in the Properties field (this not permitted for production environments) or you can enter it in the Password field of the data source descriptor. The value in the Password field overrides any password value defined in the Properties passed to the JDBC Driver when creating physical database connections. It is recommended that you use the Password attribute in place of the password property in the properties string because the Password value is encrypted in the configuration file (stored as the password-encrypted attribute in the jdbc-driver-params tag in the module file) and is hidden in the administration console. The Properties and Password fields are located on the administration console Data Source creation wizard or Data Source Configuration tab.
The JDBC API can also be used to programmatically specify a database user name and password as in the following.
java.sql.Connection conn = mydatasource.getConnection(“user”, “password”);
According to the JDBC specification, it’s supposed to take a database user and associated password but different vendors implement this differently. WLS, by default, treats this as an application server user and password. The pair is authenticated to see if it’s a valid user and that user is used for WLS security permission checks. By default, the user is then mapped to a database user and password using the data source credential mapper, so this API sort of follows the specification but database credentials are one-step removed from the application code. More details and the rationale are described later.
While the default approach is simple, it does mean that only one database user is doing all of the work. You can’t figure out who actually did the update and you can’t restrict SQL operations by who is running the operation, at least at the database level. Any type of per-user logic will need to be in the application code instead of having the database do it.
There are various WLS data source features that can be configured to provide some per-user information about the operations to the database.
WebLogic Data Source Security Options
This table describes the features available for WebLogic data sources to configure database security credentials and a brief description. It also captures information about the compatibility of these features with one another.
Feature
Description
Can be used with
Can’t be used with
User authentication (default)
Default getConnection(user, password) behavior – validate the input and use the
user/password in the descriptor.
Set client identifier
Proxy Session, Identity pooling, Use database credentials
Use database credentials
Instead of using the credential mapper, use the supplied user and password directly.
Set client identifier, Proxy session, Identity pooling
User authentication, Multi Data Source
Set Client Identifier
Set a client identifier property associated with the connection (Oracle and DB2 only).
Everything
Proxy Session
Set a light-weight proxy user associated with the connection (Oracle-only).
Set client identifier, Use database credentials
Identity pooling, User authentication
Identity pooling
Heterogeneous pool of connections owned by specified users.
Set client identifier, Use database credentials
Proxy session, User authentication, Labeling, Multi-datasource, Active GridLink
Note that all of these features are available with both XA and non-XA drivers.
Currently, the Proxy Session and Use Database Credentials options are on the Oracle tab of the Data Source Configuration tab of the administration console (even though the Use Database Credentials feature is not just for Oracle databases – oops). The rest of the features are on the Identity tab of the Data Source Configuration tab in the administration console (plan on seeing them all in one place in the future).
The subsequent articles will describe these features in more detail. Keep referring back to this table to see the big picture.
