If you read through the first four parts of this series on data source security, you should be an expert on this focus area.  There is one more small topic to cover related to WebLogic Resource permissions.  After that comes the test, I mean example, to see with a real set of configuration parameters what the results are with some concrete values.

WebLogic Resource Permissions

All of the discussion so far has been about database credentials that are (eventually) used on the database side.  WLS has resource credentials to control what WLS users are allowed to access JDBC resources.  These can be defined on the Policies tab on the Security tab associated with the data source.  There are four permissions: “reserve” (get a new connection), “admin”, “shrink”, and reset (plus the all-inclusive “ALL”); we will focus on “reserve” here because we are talking about getting connections.  By default, JDBC resource permissions are completely open – anyone can do anything.  As soon as you add one policy for a permission, then all other users are restricted.  For example, if I add a policy so that “weblogic” can reserve a connection, then all other users will fail to reserve connections unless they are also explicitly added.  The validation is done for WLS user credentials only, not database user credentials.  Configuration of resources in general is described at “Create policies for resource instances” http://docs.oracle.com/cd/E24329_01/apirefs.1211/e24401/taskhelp/security/CreatePoliciesForResourceInstances.html.  This feature can be very useful to restrict what code and users can get to your database.

There are the three use cases:

API	Use database credentials	User for permission checking
getConnection()	True or false	Current WLS user
getConnection(user,password)	False	User/password from API
getConnection(user,password)	True	Current WLS user

If a simple getConnection() is used or database credentials are enabled, the current user that is authenticated to the WLS system is checked. If database credentials are not enabled, then the user and password on the API are used.

Example

The following is an actual example of the interactions between identity-based-connection-pooling-enabled, oracle-proxy-session, and use-database-credentials.

On the database side, the following objects are configured.
- Database users scott; jdbcqa; jdbcqa3
- Permission for proxy: alter user jdbcqa3 grant connect through jdbcqa;
- Permission for proxy: alter user jdbcqa grant connect through jdbcqa;

The following WebLogic Data Source objects are configured.
- Users weblogic, wluser
- Credential mapping “weblogic” to “scott”
- Credential mapping "wluser" to "jdbcqa3"
- Data source descriptor configured with user “jdbcqa”
- All tests are run with Set Client ID set to true (more about that below).
- All tests are run with oracle-proxy-session set to false (more about that below).

The test program:
- Runs in servlet
- Authenticates to WLS as user “weblogic”

Use DB Credentials	Identity based	getConnection (scott,***)	getConnection (weblogic,***)	getConnection (jdbcqa3,***)	getConnection()
true	true	Identity scott Client weblogic Proxy null	weblogic fails - not a db user	User jdbcqa3 Client weblogic Proxy null	Default user jdbcqa Client weblogic Proxy null
false	true	scott fails - not a WLS user	User scott Client scott Proxy null	jdbcqa3 fails - not a WLS user	User scott Client scott Proxy null
true	false	Proxy for scott fails	weblogic fails - not a db user	User jdbcqa3 Client weblogic Proxy jdbcqa	Default user jdbcqa Client weblogic Proxy null
false	false	scott fails - not a WLS user	Default user jdbcqa Client scott Proxy null	jdbcqa3 fails - not a WLS user	Default user jdbcqa Client scott Proxy null

If Set Client ID is set to false, all cases would have Client set to null.

If this was not an Oracle thin driver, the one case with the non-null Proxy in the above table would throw an exception because proxy session is only supported, implicitly or explicitly, with the Oracle thin driver.

When oracle-proxy-session is set to true, the only cases that will pass (with a proxy of "jdbcqa") are the following.
1. Setting use-database-credentials to true and doing getConnection(jdbcqa3,…) or getConnection().
2. Setting use-database-credentials to false and doing getConnection(wluser, …) or getConnection().

Summary

There are many options to choose from for data source security.  Considerations include the number and volatility of WLS and Database users, the granularity of data access, the depth of the security identity (property on the connection or a real user), performance, coordination of various components in the software stack, and driver capabilities.  Now that you have the big picture (remember that table in part 1), you can make a more informed choice.