Data Source Security Part 2
- by Steve Felts
In Part 1, I introduced the default security behavior and listed the various options available to change that behavior. One of the key topics to understand is the difference between directly using database user and password values versus mapping from WLS user and password to the associated database values. The direct use of database credentials is relatively new to WLS, based on customer feedback. Some of the trade-offs are covered in this article.
Credential Mapping vs. Database Credentials
Each WLS data source has a credential map that is a mechanism used to map a key, in this case a WLS user, to security credentials (user and password). By default, when a user and password are specified when getting a connection, they are treated as credentials for a WLS user, validated, and are converted to a database user and password using a credential map associated with the data source. If a matching entry is not found in the credential map for the data source, then the user and password associated with the data source definition are used. Because of this defaulting mechanism, you should be careful what permissions are granted to the default user. Alternatively, you can define an invalid default user to ensure that no one can accidentally get through (in this case, you would need to set the initial capacity for the pool to zero so that the pool is populated only by valid users).
To create an entry in the credential map:
1) First create a WLS user. In the administration console, go to Security realms, select your realm (e.g., myrealm), select Users, and select New.
2) Second, create the mapping. In the administration console, go to Services, select Data sources, select your data source name, select Security, select Credentials, and select New. See http://docs.oracle.com/cd/E24329_01/apirefs.1211/e24401/taskhelp/jdbc/jdbc_datasources/ConfigureCredentialMappingForADataSource.html for more information.
The advantages of using the credential mapping are that:
1) You don’t hard-code the database user/password into a program or need to prompt for it in addition to the WLS user/password and
2) It provides a layer of abstraction between WLS security and database settings such that many WLS identities can be mapped to a smaller set of DB identities, thereby only requiring middle-tier configuration updates when WLS users are added/removed.
You can cut down the number of users that have access to a data source to reduce the user maintenance overhead. For example, suppose that a servlet has the one pre-defined, special WLS user/password for data source access, hard-wired in its code in a getConnection(user, password) call. Every WebLogic user can reap the specific DBMS access coded into the servlet, but none has to have general access to the data source. For instance, there may be a ‘Sales’ DBMS which needs to be protected from unauthorized eyes, but it contains some day-to-day data that everyone needs. The Sales data source is configured with restricted access and a servlet is built that hard-wires the specific data source access credentials in its connection request. It uses that connection to deliver only the generally needed day-to-day information to any caller. The servlet cannot reveal any other data, and no WebLogic user can get any other access to the data source. This is the approach that many large applications take and is the reasoning behind the default mapping behavior in WLS.
The disadvantages of using the credential map are that:
1) It is difficult to manage (create, update, delete) with a large number of users; it is possible to use WLST scripts or a custom JMX client utility to manage credential map entries.
2) You can’t share a credential map between data sources so they must be duplicated.
Some applications prefer not to use the credential map. Instead, the credentials passed to getConnection(user, password) should be treated as database credentials and used to authenticate with the database for the connection, avoiding going through the credential map. This is enabled by setting the “use-database-credentials” to true. See http://docs.oracle.com/cd/E24329_01/apirefs.1211/e24401/taskhelp/jdbc/jdbc_datasources/ConfigureOracleParameters.html "Configure Oracle parameters" in Oracle WebLogic Server Administration Console Help.
Use Database Credentials is not currently supported for Multi Data Source configurations. When enabled, it turns off credential mapping on Generic and Active GridLink data sources for the following attributes:
1. identity-based-connection-pooling-enabled (this interaction is available by patch in 10.3.6.0).
2. oracle-proxy-session (this interaction is first available in 10.3.6.0).
3. set client identifier (this interaction is available by patch in 10.3.6.0). Note that in the data source schema, the set client identifier feature is poorly named “credential-mapping-enabled”. The documentation and the console refer to it as Set Client Identifier.
To review the behavior of credential mapping and using database credentials:
- If using the credential map, there needs to be a mapping for each WLS user to database user for those users that will have access to the database; otherwise the default user for the data source will be used. If you always specify a user/password when getting a connection, you only need credential map entries for those specific users.
- If using database credentials without specifying a user/password, the default user and password in the data source descriptor are always used. If you specify a user/password when getting a connection, that user will be used for the credentials. WLS users are not involved at all in the data source connection process.
