Data Source Security Part 5

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.




Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

The official blog for Oracle WebLogic Server fans and followers!

Stay Connected

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
5
6
7
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today