Monday Oct 22, 2012

Instructions on how to configure a WebLogic Cluster and use it with Oracle Http Server

On October 17th I delivered a webcast on WebLogic Clustering that included a demo with Apache as the proxy server.  I realized that many steps are needed to set up the configuration I used during the demo.  The purpose of this article is to go through these steps to show how quickly and easily one can define a new cluster and then proxy requests via an Oracle Http Server (OHS).

The domain configuration wizard offers the option to create a cluster.  The administration console or WLST, the Weblogic scripting tool can also be used to define a new cluster.  It can be created at any time but the servers that will participate in it cannot be in a running state.

Cluster Creation using the configuration wizard

Network and architecture requirements need to be considered while choosing between unicast and multicast.

Multicast Vs. Unicast with WebLogic Clustering is of great help to make the best decision between the two messaging modes.  In addition, Configure Cluster offers details on each single field displayed above.

After this initial configuration page, individual servers could be assigned to this newly created cluster although servers can be added later to the cluster.  What is not recommended is for the Admin server to participate in a cluster as the main purpose of the Admin server is to perform the bulk of the processing for the domain.  Servers need to stop before being assigned to a cluster.  There is also no minimum number of servers that have to participate in the cluster.

At this point the configuration should be done and the cluster created successfully.  This can easily be verified from the console.

Each clustered managed server can be launched to join the cluster.  

At startup the following messages should be logged for each clustered managed server:

<Notice> <WeblogicServer> <BEA-000365> <Server state changed to STARTING>
<Notice> <Cluster> <BEA-000197> <Listening for announcements from cluster using 
messaging_mode cluster messaging>
<Notice> <Cluster> <BEA-000133> <Waiting to synchronize with other running members 
of cluster_name

It's time to try sending requests to the cluster and we will do this with the help of Oracle Http Server to play the role of a proxy server to demonstrate load balancing. 

Proxy Server configuration 

The first step is to download Weblogic Server Web Server Plugin that will enhance the web server by handling requests aimed at being sent to the Weblogic cluster.  For our test Oracle Http Server (OHS) will be used.  However plug-ins are also available for Apache Http serverMicrosoft Internet Information Server (IIS), Oracle iPlanet Webserver or even WebLogic Server with the HttpClusterServlet.

Once OHS is installed on the system, the configuration file, mod_wl_ohs.conf, will need to be altered to include Weblogic proxy specifics.

First of all, add the following directive to instruct Apache to load the Weblogic shared object module extracted from the plugins file just downloaded.

LoadModule weblogic_module modules/  

and then create an IfModule directive to encapsulate the following location block so that proxy will be enabled by path (each request including /wls will be directed directly to the WebLogic Cluster).  You could also proxy requests by MIME type using MatchExpression in the Location block.

<IfModule weblogic_module>
<Location /wls>
   SetHandler       weblogic-handler
   PathTrim         /wls
   WebLogicCluster  MS1_URL:port,MS2_URL:port
   Debug 	    ON
   WLLogFile        c:/tmp/global_proxy.log 
   WLTempDir        "c:/myTemp"
   DebugConfigInfo  On

SetHandler specifies the handler for the plug-in module 

PathTrim will instruct the plug-in to trim /w ls from the URL before forwarding the request to the cluster.

The list of WebLogic Servers defined in WeblogicCluster could contain a mixed set of clustered and single servers.  However, the dynamic list returned for this parameter will only contain valid clustered servers and may contain more servers if not all clustered servers are listed in WeblogicCluster.

Testing proxy and load balancing

It's time to start OHS web server which should at this point be configured correctly to proxy requests to the clustered servers.  By default round-robin is the load balancing strategy set by WebLogic.

Testing the load balancing can be easily done by disabling cookies on your browser given that a request containing a cookie attempts to connect to the primary server. If that attempt fails, the plug-in attempts to make a connection to the next available server in the list in a round-robin fashion.  With cookies enabled, you could use two different browsers to test the load balancing with a JSP page that contains the following:

<%@ page contentType="text/html; charset=iso-8859-1" language="java"  %> 

<%  String path = request.getContextPath();   String getProtocol=request.getScheme();   String getDomain=request.getServerName();   String getPort=Integer.toString(request.getLocalPort());   String getPath = getProtocol+"://"+getDomain+":"+getPort+path+"/"; %> <html> <body> Receiving Server <%=getPath%> </body> </html> 

Assuming that you name the JSP page Test.jsp and the webapp that contains it TestApp, your browsers should open the following URL:


Each browser should connect to a different clustered server and this simple JSP should confirm that.  The webapp that contains the JSP needs to be deployed to the cluster.

You can also verify that the load is correctly balanced by looking at the proxy log file.  Each request generates a set of log entries that starts with :

timestamp ================New Request:

Each request is associated with a primary server and a secondary server if one is available.  For our test request, the following entries should appear in the log as well:

Using Uri /wls/TestApp/Test.jsp After trimming path: '/TestApp/Test.jsp' The final request string is '/TestApp/Test.jsp'

If an exception occurs, it should also be logged in the proxy log file with the prefix:

timestamp *******Exception type  


DebugConfigInfo enables runtime statistics and the production of configuration information.  For security purposes, this parameter should be turned off in production.

http://webserver_host:port/path/xyz.jsp?__WebLogicBridgeConfig will display a proxy bridge page detailing the plugin configuration followed by runtime statistics which could help in diagnosing issues along with the analyzing of the proxy log file.  In our example the url would be:


Here is how the top section of the screen can look like:

The bottom part of the page contains runtime statistics, here is a snippet of it (unrelated with the previous JSP example).  

This entire plugin configuration should be very similar with other web servers, what varies is the name of the proxy server configuration file.

So, as you can see, it only takes a few minutes to configure a Weblogic cluster and get servers to join it. 

Wednesday Oct 17, 2012

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”  This feature can be very useful to restrict what code and users can get to your database.

There are the three use cases:

Use database credentials
User for permission checking
True or false
Current WLS user
User/password from API
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
 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().


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.

Monday Oct 15, 2012

Data Source Security Part 4

So far, I have covered Client Identity and Oracle Proxy Session features, with WLS or database credentials.  This article will cover one more feature, Identify-based pooling.  Then, there is one more topic to cover - how these options play with transactions.

Identity-based Connection Pooling

An identity based pool creates a heterogeneous pool of connections.  This allows applications to use a JDBC connection with a specific DBMS credential by pooling physical connections with different DBMS credentials.  The DBMS credential is based on either the WebLogic user mapped to a database user or the database user directly, based on the “use database credentials” setting as described earlier. Using this feature enabled with “use database credentials” enabled seems to be what is proposed in the JDBC standard, basically a heterogeneous pool with users specified by getConnection(user, password).

The allocation of connections is more complex if Enable Identity Based Connection Pooling attribute is enabled on the data source.  When an application requests a database connection, the WebLogic Server instance selects an existing physical connection or creates a new physical connection with requested DBMS identity.

The following section provides information on how heterogeneous connections are created:
1. At connection pool initialization, the physical JDBC connections based on the configured or default “initial capacity” are created with the configured default DBMS credential of the data source.
2. An application tries to get a connection from a data source.
3a. If “use database credentials” is not enabled, the user specified in getConnection is mapped to a DBMS credential, as described earlier.  If the credential map doesn’t have a matching user, the default DBMS credential is used from the datasource descriptor.
3b. If “use database credentials” is enabled, the user and password specified in getConnection are used directly.
4. The connection pool is searched for a connection with a matching DBMS credential.
5. If a match is found, the connection is reserved and returned to the application.
6. If no match is found, a connection is created or reused based on the maximum capacity of the pool:
- If the maximum capacity has not been reached, a new connection is created with the DBMS credential, reserved, and returned to the application.
- If the pool has reached maximum capacity, based on the least recently used (LRU) algorithm, a physical connection is selected from the pool and destroyed. A new connection is created with the DBMS credential, reserved, and returned to the application.

It should be clear that finding a matching connection is more expensive than a homogeneous pool.  Destroying a connection and getting a new one is very expensive.  If you can use a normal homogeneous pool or one of the light-weight options (client identity or an Oracle proxy connection), those should be used instead of identity based pooling.

Regardless of how physical connections are created, each physical connection in the pool has its own DBMS credential information maintained by the pool. Once a physical connection is reserved by the pool, it does not change its DBMS credential even if the current thread changes its WebLogic user credential and continues to use the same connection.

To configure this feature, select Enable Identity Based Connection Pooling.  See  "Enable identity-based connection pooling for a JDBC data source" in Oracle WebLogic Server Administration Console Help.

You must make the following changes to use Logging Last Resource (LLR) transaction optimization with Identity-based Pooling to get around the problem that multiple users will be accessing the associated transaction table.
- You must configure a custom schema for LLR using a fully qualified LLR table name. All LLR connections will then use the named schema rather than the default schema when accessing the LLR transaction table. 
- Use database specific administration tools to grant permission to access the named LLR table to all users that could access this table via a global transaction. By default, the LLR table is created during boot by the user configured for the connection in the data source. In most cases, the database will only allow access to this user and not allow access to mapped users.

Connections within Transactions

Now that we have covered the behavior of all of these various options, it’s time to discuss the exception to all of the rules.  When you get a connection within a transaction, it is associated with the transaction context on a particular WLS instance.

When getting a connection with a data source configured with non-XA LLR or 1PC (using the JTS driver) with global transactions, the first connection obtained within the transaction is returned on subsequent connection requests regardless of the values of username/password specified and independent of the associated proxy user session, if any. The connection must be shared among all users of the connection when using LLR or 1PC.

For XA data sources, the first connection obtained within the global transaction is returned on subsequent connection requests within the application server, regardless of the values of username/password specified and independent of the associated proxy user session, if any.  The connection must be shared among all users of the connection within a global transaction within the application server/JVM.

Friday Oct 12, 2012

Data Source Security Part 3

In part one, I introduced the security features and talked about the default behavior.  In part two, I defined the two major approaches to security credentials: directly using database credentials and mapping WLS user credentials to database credentials.  Now it's time to get down to a couple of the security options (each of which can use database credentials or WLS credentials).

Set Client Identifier on Connection

When "Set Client Identifier" is enabled on the data source, a client property is associated with the connection.  The underlying SQL user remains unchanged for the life of the connection but the client value can change.  This information can be used for accounting, auditing, or debugging.  The client property is based on either the WebLogic user mapped to a database user using the credential map or is the database user parameter directly from the getConnection() method, based on the “use database credentials” setting described earlier.

To enable this feature, select “Set Client ID On Connection” in the Console.  See "Enable Set Client ID On Connection for a JDBC data source" in Oracle WebLogic Server Administration Console Help.

The Set Client Identifier feature is only available for use with the Oracle thin driver and the IBM DB2 driver, based on the following interfaces.

For pre-Oracle 12c, oracle.jdbc.driver.OracleConnection.setClientIdentifier(client) is used.  See for more information about how to use this for auditing and debugging.   You can get the value using getClientIdentifier()  from the driver.  To get back the value from the database as part of a SQL query, use a statement like the following.
“select sys_context('USERENV','CLIENT_IDENTIFIER') from DUAL”.

Starting in Oracle 12c, java.sql.Connection.setClientInfo(“OCSID.CLIENTID", client) is used.  This is a JDBC standard API, although the property values are proprietary.  A problem with setClientIdentifier usage is that there are pieces of the Oracle technology stack that set and depend on this value.  If application code also sets this value, it can cause problems. This has been addressed with setClientInfo by making use of this method a privileged operation. A well-managed container can restrict the Java security policy grants to specific namespaces and code bases, and protect the container from out-of-control user code. When running with the Java security manager, permission must be granted in the Java security policy file for
permission "oracle.jdbc.OracleSQLPermission" "clientInfo.OCSID.CLIENTID";
Using the name “OCSID.CLIENTID" allows for upward compatible use of

“select sys_context('USERENV','CLIENT_IDENTIFIER') from DUAL”

or use the JDBC standard API java.sql.getClientInfo(“OCSID.CLIENTID") to retrieve the value.

This value in the Oracle USERENV context can be used to drive the Oracle Virtual Private Database (VPD) feature to create security policies to control database access at the row and column level. Essentially, Oracle Virtual Private Database adds a dynamic WHERE clause to a SQL statement that is issued against the table, view, or synonym to which an Oracle Virtual Private Database security policy was applied.  See Using Oracle Virtual Private Database to Control Data Access for more information about VPD.  Using this data source feature means that no programming is needed on the WLS side to set this context; it is set and cleared by the WLS data source code.

For the IBM DB2 driver, is used for older releases (prior to version 9.5).  This specifies the current client user name for the connection. Note that the current client user name can change during a connection (unlike the user).  This value is also available in the CURRENT CLIENT_USERID special register.  You can select it using a statement like


When running the IBM DB2 driver with JDBC 4.0 (starting with version 9.5), java.sql.Connection.setClientInfo(“ClientUser”, client) is used.  You can retrieve the value using java.sql.Connection.getClientInfo(“ClientUser”) instead of the DB2 proprietary API (even if set setDB2ClientUser()). 

Oracle Proxy Session

Oracle proxy authentication allows one JDBC connection to act as a proxy for multiple (serial) light-weight user connections to an Oracle database with the thin driver.  You can configure a WebLogic data source to allow a client to connect to a database through an application server as a proxy user. The client authenticates with the application server and the application server authenticates with the Oracle database. This allows the client's user name to be maintained on the connection with the database.

Use the following steps to configure proxy authentication on a connection to an Oracle database.
1. If you have not yet done so, create the necessary database users.
2. On the Oracle database, provide CONNECT THROUGH privileges. For example:
where “connectionuser” is the name of the application user to be authenticated and “dbuser” is an Oracle database user.
3. Create a generic or GridLink data source and set the user to the value of dbuser.
4a. To use WLS credentials, create an entry in the credential map that maps the value of wlsuser to the value of dbuser, as described earlier.  
4b. To use database credentials, enable “Use Database Credentials”, as described earlier.
5. Enable Oracle Proxy Authentication, see "Configure Oracle parameters" in Oracle WebLogic Server Administration Console Help.
6. Log on to a WebLogic Server instance using the value of wlsuser or dbuser.
6. Get a connection using getConnection(username, password).  The credentials are based on either the WebLogic user that is mapped to a database user or the database user directly, based on the “use database credentials” setting. 

You can see the current user and proxy user by executing:

“select user, sys_context('USERENV','PROXY_USER') from DUAL".

Note: getConnection fails if “Use Database Credentials” is not enabled and the value of the user/password is not valid for a WebLogic Server user.  Conversely, it fails if “Use Database Credentials” is enabled and the value of the user/password is not valid for a database user.

A proxy session is opened on the connection based on the user each time a connection request is made on the pool. The proxy session is closed when the connection is returned to the pool.  Opening or closing a proxy session has the following impact on JDBC objects.
- Closes any existing statements (including result sets) from the original connection.
- Clears the WebLogic Server statement cache.
- Clears the client identifier, if set.
-The WebLogic Server test statement for a connection is recreated for every proxy session.

These behaviors may impact applications that share a connection across instances and expect some state to be associated with the connection.

Oracle proxy session is also implicitly enabled when use-database-credentials is enabled and getConnection(user, password) is called,starting in WLS Release 10.3.6.  Remember that this only works when using the Oracle thin driver.

To summarize, the definition of oracle-proxy-session is as follows.
- If proxy authentication is enabled and identity based pooling is also enabled, it is an error.
- If a user is specified on getConnection() and identity-based-connection-pooling-enabled is false, then oracle-proxy-session is treated as true implicitly (it can also be explicitly true).
- If a user is specified on getConnection() and identity-based-connection-pooling-enabled is true, then oracle-proxy-session is treated as false.

Tuesday Oct 09, 2012

Data Source Security Part 2

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 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 "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

2. oracle-proxy-session (this interaction is first available in

3. set client identifier (this interaction is available by patch in  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.

Monday Oct 08, 2012

Data Source Security Part 1

I’ve written a couple of articles on how to store data source security credentials using the Oracle wallet.  I plan to write a few articles on the various types of security available to WebLogic Server (WLS) data sources.  There are more options than you might think!

There have been several enhancements in this area in WLS 10.3.6.  There are a couple of more enhancements planned for release WLS 12.1.2 that I will include here for completeness.  This isn’t intended as a teaser.  If you call your Oracle support person, you can get them now as minor patches to WLS 10.3.6.  

The current security documentation is scattered in a few places, has a few incorrect statements, and is missing a few topics.  It also seems that the knowledge of how to apply some of these features isn’t written down.  The goal of these articles is to talk about WLS data source security in a unified way and to introduce some approaches to using the available features. 

Introduction to WebLogic Data Source Security Options

By default, you define a single database user and password for a data source.  You can store it in the data source descriptor or make use of the Oracle wallet.  This is a very simple and efficient approach to security.  All of the connections in the connection pool are owned by this user and there is no special processing when a connection is given out.  That is, it’s a homogeneous connection pool and any request can get any connection from a security perspective (there are other aspects like affinity).  Regardless of the end user of the application, all connections in the pool use the same security credentials to access the DBMS.   No additional information is needed when you get a connection because it’s all available from the data source descriptor (or wallet).

java.sql.Connection conn =  mydatasource.getConnection();

Note: You can enter the password as a name-value pair in the Properties field (this not permitted for production environments) or you can enter it in the Password field of the data source descriptor. The value in the Password field overrides any password value defined in the Properties passed to the JDBC Driver when creating physical database connections. It is recommended that you use the Password attribute in place of the password property in the properties string because the Password value is encrypted in the configuration file (stored as the password-encrypted attribute in the jdbc-driver-params tag in the module file) and is hidden in the administration console.  The Properties and Password fields are located on the administration console Data Source creation wizard or Data Source Configuration tab.

The JDBC API can also be used to programmatically specify a database user name and password as in the following. 

java.sql.Connection conn = mydatasource.getConnection(“user”, “password”);

According to the JDBC specification, it’s supposed to take a database user and associated password but different vendors implement this differently.  WLS, by default, treats this as an application server user and password.  The pair is authenticated to see if it’s a valid user and that user is used for WLS security permission checks.  By default, the user is then mapped to a database user and password using the data source credential mapper, so this API sort of follows the specification but database credentials are one-step removed from the application code.  More details and the rationale are described later.

While the default approach is simple, it does mean that only one database user is doing all of the work.  You can’t figure out who actually did the update and you can’t restrict SQL operations by who is running the operation, at least at the database level.   Any type of per-user logic will need to be in the application code instead of having the database do it. 

There are various WLS data source features that can be configured to provide some per-user information about the operations to the database.

WebLogic Data Source Security Options

This table describes the features available for WebLogic data sources to configure database security credentials and a brief description.  It also captures information about the compatibility of these features with one another.

Feature Description Can be used with Can’t be used with

User authentication (default)

Default getConnection(user, password) behavior – validate the input and use the user/password in the descriptor. Set client identifier Identity pooling, Use database credentials
Use database credentials Instead of using the credential mapper, use the supplied user and password directly. Set client identifier, Proxy session, Identity pooling User authentication, Multi Data Source
Set Client Identifier Set a client identifier property associated with the connection (Oracle and DB2 only). Everything
Proxy Session Set a light-weight proxy user associated with the connection (Oracle-only). Set client identifier, Use database credentials Identity pooling
Identity pooling Heterogeneous pool of connections owned by specified users. Set client identifier, Use database credentials Proxy session, User authentication, Labeling, Multi-datasource, Active GridLink

Note that all of these features are available with both XA and non-XA drivers.

Currently, the Proxy Session and Use Database Credentials options are on the Oracle tab of the Data Source Configuration tab of the administration console (even though the Use Database Credentials feature is not just for Oracle databases – oops).  The rest of the features are on the Identity tab of the Data Source Configuration tab in the administration console (plan on seeing them all in one place in the future).

The subsequent articles will describe these features in more detail.  Keep referring back to this table to see the big picture.

Thursday Oct 04, 2012

Oracle OpenWorld Update -- Developing Java Applications in the Cloud: Oracle Java Cloud Service

Today we are focused on the Oracle Java Cloud Service. There are multiple sessions on this topic. In this particular session (which will run multiple times), learn how you can use the Oracle Public Cloud Java Cloud Service to exponentially decrease the turn-around time for the development and production roll-out of your WebLogic Server applications. This session will provide an overview the Oracle Java Cloud Service and demonstrate some of the product's powerful developer productivity features. For more information about this and other Cloud Application Foundation sessions, review the Oracle Cloud Application Foundation Focus On document.


Thursday, Oct 4, 11.15-12.15pm, Moscone South, Room 304

Thursday, Oct 4, 2:15 PM - 3:15 PM, Marriott Marquis - Foothill F

Wednesday Oct 03, 2012

Oracle OpenWorld Update -- Get in the Cloud Now: Building Real Applications with the Java Cloud Service

Today we want to highlight a really exciting session focused on what it takes to build a typical application on the Oracle Cloud using the Java Cloud Service. Come to this session to learn the technical ins and outs of building such applications, what services you can use and how you should evaluate the Java Cloud Service for your applications. Whether you are new to the cloud or a veteran of building cloud solutions on other platforms, this will be a dive into the practical issues in the development - tools, build environment, and deployment approaches - that will help you go back home and try the Java Cloud Service out with your applications. This session will include a live demo and a sample application you will be able to try out yourself on the Java Cloud Service. For more information about this and other Cloud Application Foundation sessions, review the Oracle Cloud Application Foundation Focus On document

Details: Wednesday, Oct 3,  1.15 -- 2.15pm, Marriott Marquis Foothill F


Tuesday Oct 02, 2012

Oracle OpenWorld Update -- General Session: Oracle Fusion Middleware Strategies Driving Business Innovation

Today we kick it off with a fantastic general session focused on Fusion Middleware by Hasan Rizvi. Oracle Fusion Middleware is the leading business innovation platform for the enterprise and the cloud. Innovative businesses today are utilizing new platform technologies for their enterprise applications—embracing social, mobile, and cloud technologies. Convergence of these three technologies opens the door for business innovation—changing how customers interact, employees collaborate, and IT manages services. Successful adoption requires a comprehensive middleware platform that delivers secure multichannel user experiences, integrates back-end systems, and supports flexible deployment. In this general session, hear from Hasan Rizvi, and many of our customers how they leverage new innovations in their applications and customers achieve their business innovation goals with Oracle Fusion Middleware. For more information about this and other Fusion Middleware sessions, review the Oracle Fusion Middleware Focus On document.

Details: Tuesday, Oct 2, 10:15 AM - 11:15 AM - Moscone North - Hall D


Oracle OpenWorld Update -- Highly Available WebLogic Messaging Architectures: Sharing a Customer Experience with Comcast

This session will describe a Comcast’s hands-on  experience using WebLogic JMS as their high-performance enterprise messaging system including high availability, and disaster recovery capabilities as Comcast is rolling out a cross-site active-active message bus. In the session, we will cover the following:

  • Key capabilities in WebLogic JMS that enabled Comcast to design such an architecture
  • Details of the architecture put in place
  • Details about application design needed to make all of this successful
  • Failover and fail back processes

The results from this new architecture are higher availability, better performance, more flexibility, and reduced costs through better utilization of hardware and improved manageability.

For more information about this and other WebLogic sessions, review the Oracle WebLogic Focus On document here.

Details: Tuesday, Oct 2, 5-6pm, Moscone South Room 306

Monday Oct 01, 2012

Oracle OpenWorld Update -- Scaling Infrastructure to Meet Business Growth: A Coherence Customer Panel

Today being the Monday of OpenWorld is packed with great content and sessions. I have already blogged about the general session by Ajay Patel and the classic Cloud Application Foundation roadmap and strategy session by Mike Lehmann. But we will be remiss if we don’t list the customer panel for Coherence. Come listen to customers spanning a wide variety of industries such as consumer goods, railways, and agricultural biotechnology discuss how Oracle Coherence enables business growth, cost cutting, and improved customer experience. You will learn how Coherence helps scale services cost-effectively, improve performance, and assure service availability in both on-premises and cloud deployments. Each customer will present details of their specific use cases, benefits and war stories of developing, deploying and managing some of the largest data grid deployments in the world. The session will be moderated by Cameron Purdy, VP of Development, and Mr. Coherence himself J For more information about this and other Coherence sessions, review the Coherence Focus on document.

Monday, 10/1, 12:15 p.m. - 1:15 p.m., Moscone South Room 309


The official blog for Oracle WebLogic Server fans and followers!

Stay Connected


« October 2012 »