The following sections provide information on advanced interoperability topics when WebLogic Server applications interoperate with AQ JMS.
■ Section 8.4.1, "Security Considerations" ■ Section 8.4.2, "WebLogic Messaging Bridge"
■ Section 8.4.3, "Stand-alone WebLogic AQ JMS Clients"
8.4.1 Security Considerations
Stand-alone clients and server-side applications have different security semantics and configuration. If security is a concern, read this section carefully and also reference the WebLogic lock-down document for general information on how to secure a WebLogic Server or Cluster (see Securing a Production Environment for Oracle WebLogic Server). The following section outlines security considerations for this release:
■ Section 8.4.1.1, "Configuring AQ Destination Security"
■ Section 8.4.1.2, "Access to JNDI Advertised Destinations and Connection Factories" ■ Section 8.4.1.3, "Controlling Access to Destinations that are Looked Up using the
Advanced Topics
8.4.1.1 Configuring AQ Destination Security
ENQUEUE and/or DEQUEUE permission must be configured for the database user in AQ to allow destination lookups as well as to allow enqueues and dequeues.
The following usernames must be given enqueue and/or dequeue permission:
■ For stand-alone clients:
– The configured JMS Foreign Server username, as specified using the
java.naming.security.principal property.
– For Java code that passes a username using the JMS ConnectionFactory API
createConnection() method, this username requires permission.
■ For server-side applications:
– The Database User Name is configured on the WebLogic Data Source.
– Do not give permission for a username specified for JDBC Data Source clients that pass a username using the JMS ConnectionFactory API
createConnection() method: this username is a WebLogic username, not a database username.
To understand which JDBC connection credentials and permissions that are used for AQ lookups, enqueues, and dequeues, see "Queue Security and Access Control" in Oracle Streams Advanced Queuing User's Guide.
8.4.1.2 Access to JNDI Advertised Destinations and Connection Factories
As described earlier, local JNDI names for connection factories and destinations must be configured as part of the JMS Foreign Server configuration task. You can optionally configure security policies on these JNDI names, so access checks occur during JNDI lookup based on the current WebLogic credentials. The current WebLogic credentials depend on the client type.
Once an application's WebLogic JNDI lookup security policy credential check passes for a destination, a JMS Foreign Server destination automatically looks up the destination resources in Oracle AQ using a JDBC connection.
For stand-alone clients, the credential used for the second part of a destination lookup process are based on the username and password that is configured on the JMS Foreign Server.
For server-side application JDBC Data Source clients, the credential used for this second destination lookup is based on the database username and password configured as part of the data source. Note that the credential used to gain access to this data source is the current WebLogic credential. It is possible to configure a WebLogic security policies on the data source. The WebLogic data source Identity Based Connection Pooling feature is not supported for this purpose.
As previously mentioned, the database credential must have AQ JMS enqueue or dequeue permission on a destination in order to be able to successfully lookup the destination. See Section 8.4.1.1, "Configuring AQ Destination Security."
Note: A permission failure while looking up a destination will manifest as a "name not found" exception thrown back to application caller, not a security exception.
Advanced Topics
8.4.1.3 Controlling Access to Destinations that are Looked Up using the JMS API
The JMS QueueSession and TopicSession APIs provide an alternative to JNDI for looking up destinations, named createQueue() and createTopic() respectively. See "How to Lookup a Destination" in Developing JMS Applications for Oracle WebLogic Server.
The createQueue() and createTopic() calls use the database credential associated with the JMS connection. The following sections describe how to set this credential.
8.4.1.3.1 Additional Security Configuration for Stand-alone Clients The following section provides security configuration information for stand-alone clients:
■ Network communication from a client into WebLogic occurs when establishing a
JNDI initial context and when performing any subsequent JNDI lookups. To ensure secure communication and avoid plain text on the wire, use an SSL capable protocol (such as t3s or https). The credentials used for WebLogic login, as well as the JMS Foreign Server credentials that are configured for database login, are passed plain-text on the wire unless SSL is configured.
■ Network communication is direct from the client to the database when
communicating with AQ. This communication is controlled by the JDBC URL configuration, and is in plain text unless the JDBC URL is configured to use SSL. Stand-alone clients communicate directly with the database over a database connection when using the AQ JMS APIs, their JMS requests do not route through a WebLogic server.
■ WebLogic Server username and password: The network login from a client into
WebLogic is performed as part of establishing the JNDI initial context. The
username and password properties that are optionally supplied when creating the context become the WebLogic identity (the property names are
Context.SECURITY_PRINCIPAL = "java.naming.security.principal" and
Context.SECURITY_CREDENTIALS = "java.naming.security.credentials"
respectively). This becomes the credential that is checked for subsequent JNDI lookups. The credential is also implicitly associated with current thread, and so becomes the credential used for subsequent WebLogic operations on the same thread, but this is not the credential used for AQ JMS operations.
■ The javax.jms.ConnectionFactory createConnection() method has an optional username and password. For stand-alone clients, these override the context credentials that were configured as part of the JMS Foreign Server configuration. AQ JMS creates a database connection with the specified user identity. If
createConnection() is called without a username and password, then the database connection is created using the username and password that was configured as part of the JMS Foreign Server configuration.
■ Do not include a username/password directly in the JDBC URL. Instead use the
JMS Foreign Server username and password.
■ Do not configure a username and password on the JMS Foreign Server connection
factory. The resulting behavior is unsupported.
8.4.1.3.2 Additional Security Configurations for Server-side Applications The following section provides security configuration information for server-side applications.
■ Do not configure a java.naming.security.principal or a credential on the JMS Foreign Server unless the same JMS Foreign Server is also being used to support stand-alone clients.
Advanced Topics
■ Do not configure a username and password on the JMS Foreign Server connection
factory. The resulting behavior is unsupported.
■ Network communication from the server to the database (server-side applications)
is controlled by data source configuration, and is in plain text unless the data source is configured to use SSL.
■ The javax.jms.ConnectionFactory createConnection() method has an optional username and password. For server-side JMS AQ applications, the method assumes the username is for a WebLogic user and authenticates it with the WebLogic server. This behavior deviates from other kinds of JMS AQ clients, where the username is instead treated as a database user. When configured with a WebLogic data source, AQ JMS delegates the authentication to the WebLogic data source and AQ JMS inherits the WebLogic user semantics.
■ When an AQ JMS foreign server is configured with a WebLogic data source, the
data source is exposed to general-purpose JDBC usage. Oracle recommends that you secure the data source as described in "Using Roles and Policies to Secure JDBC Data Sources" in Administering JDBC Data Sources for Oracle WebLogic Server.
■ WebLogic Server username and password: WebLogic credentials are checked
when accessing secured names in JNDI, and accessing secured data sources. Server side applications automatically assume the same WebLogic credentials as the caller that invoked the application, or, in the case of MDBs, this credential is configurable as part of the MDB configuration.
■ The WebLogic data source Identity Based Connection Pooling feature is not
supported.
■ JNDI context credentials: Specifying credentials as part of setting up a JNDI
context within a server-side application is usually not necessary, and is not normally recommended. This creates a new credential that overrides the application's current credentials. In other words, the username and password properties that are optionally supplied when creating the context become the WebLogic identity and replace any current identity (the property names are
Context.SECURITY_PRINCIPAL = "java.naming.security.principal" and
Context.SECURITY_CREDENTIALS = "java.naming.security.credentials"
respectively). The optional new credential is implicitly associated with current thread, and so becomes the credential used for subsequent WebLogic operations on the same thread, such as JNDI lookups. The new credential is not the credential used for AQ JMS operations.
8.4.2 WebLogic Messaging Bridge
A WebLogic Messaging Bridge communicates with the configured source and target bridge destinations. For each mapping of a source destination to a target destination, you must configure a messaging bridge instance. Each messaging bridge instance defines the source and target destination for the mapping, a message filtering selector, a QOS, transaction semantics, and various reconnection parameters.
If you have AQ foreign destinations that are not local to the server running the application or MDBs sending and receiving messages, you must configure a
messaging bridge instance on the server that is local to the AQ foreign destinations. A local database connection is used in the process of sending and receiving messages from AQ destinations.
For more information on the WebLogic Messaging Bridge, see "Understanding the Messaging Bridge" in Administering the WebLogic Messaging Bridge for Oracle WebLogic Server.
Advanced Topics
8.4.2.1 Create a Messaging Bridge Instance
The section provides the major steps in creating a messaging bridge between AQ destinations configured as foreign destinations in one domain and applications/MDBs running in another domain:
1. Create the bridge instance on the server where AQ destinations configured as