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 scottClient weblogicProxy null
weblogic fails - not a db user
User jdbcqa3Client weblogicProxy null
Default user jdbcqaClient weblogicProxy null
false
true
scott fails - not a WLS user
User scottClient scottProxy null
jdbcqa3 fails - not a WLS user
User scottClient scottProxy null
true
false
Proxy for scott fails
weblogic fails - not a db user
User jdbcqa3Client weblogicProxy jdbcqa
Default user jdbcqaClient weblogicProxy null
false
false
scott fails - not a WLS user
Default user jdbcqaClient scottProxy null
jdbcqa3 fails - not a WLS user
Default user jdbcqaClient scottProxy 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.
