Controlling Access to Destinations that are Looked Up using the JMS API

7-12 Configuring and Managing JMS for Oracle WebLogic Server 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 applications 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 7.4.1.1, Configuring AQ Destination Security.

7.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 Programming JMS 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.

7.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 Interoperating with Oracle AQ JMS 7-13 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 usernamepassword 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.

7.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. ■ 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 Security for JDBC Data Sources in Configuring and Managing 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 applications 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 = 7-14 Configuring and Managing JMS for Oracle WebLogic Server 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.

7.4.2 WebLogic Messaging Bridge