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.
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 |
| getConnection |
| getConnection |
|true||true||Identity scott |
|weblogic fails - not a db user ||User jdbcqa3 |
|Default user jdbcqa |
|false||true||scott fails - not a WLS user ||User scott |
|jdbcqa3 fails - not a WLS user ||User scott |
|true||false||Proxy for scott fails ||weblogic fails - not a db user ||User jdbcqa3 |
|Default user jdbcqa |
|false||false||scott fails - not a WLS user ||Default user jdbcqa |
|jdbcqa3 fails - not a WLS user ||Default user jdbcqa |
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().
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.