Weblogic Integration for secured JMS Modules

This is a follow up of the user list thread : http://mail-archives.apache.org/mod_mbox/cxf-users/201601.mbox/%3CCAC88joDPa%2BRmY02jSrnDdVV8ctyA0wGP_Z9j0ipZhWHSCvEybA%40mail.gmail.com%3E

When accessing JMS ressources of a secured Weblogic JMS Module, the weblogic security model enforces the presence of a valid user (i.e. matching the security constraint) on the thread interacting with the ressource (i.e. creating a MessageConsumer or MessageProducer on a JMS session).
This is documented here : https://docs.oracle.com/cd/E13222_01/wls/docs81/jndi/jndi.html#467275

This user can be logged in either by having either an open InitialContext, or a JAAS LoginContext, active at the time of the security-check.

In the CXF 2.x and 3.x implementations, such a condition is met when accessing the JNDI (to retreive the ConnectionFactory or Destination queue objects), but the JNDI context is closed almost immediately after this step, meaning :
1) When sending SOAP/JMS calls, the calling thread does not have an open InitialContext anymore
2) When exposing a SOAP/JMS service, the poller threads that start never even had a logged in user at any point in time

This leads to a JMS Security exception. For the server side :

Caused by: weblogic.jms.common.JMSSecurityException: Access denied to
resource: type=<jms>, application=...
at
weblogic.jms.common.JMSSecurityHelper.checkPermission(JMSSecurityHelper.java:160)
...
at
org.apache.cxf.transport.jms.util.PollingMessageListenerContainer.createConsumer

In CXF 2.X, the SpringJMS based implementation would allow any user to override the polling threads to actually perform InitialContext injection, as suggested here : http://stackoverflow.com/questions/19849766/org-springframework-jms-jmssecurityexception-access-denied-to-resource-type-j

In CXF 3.2 (not yet released), we have a workaround thanks to CXF-6702, where we can override the thread pool to perform such an injection too (although this suffers from several concerns, such as the difficulty to inject different credentials for different endpoints).

An ideal solution would be to match SpringJMS behaviour of the "exposeAccessContext" function : http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jndi/JndiObjectFactoryBean.html . That is, CXF would provide an option (say, on JMSConfig), to expose an InitialContext in the threads performing JMS API calls through JNDI.

I will shortly provide a draft patch for this behavior, as a base for discussion.