[jira] [Created] (CXF-7176) CLONE - Weblogic Integration for secured JMS Modules

["Jérôme Tamborini (JIRA)" <ji...@apache.org>]

Jérôme Tamborini created CXF-7176:
-------------------------------------

             Summary: CLONE - Weblogic Integration for secured JMS Modules
                 Key: CXF-7176
                 URL: https://issues.apache.org/jira/browse/CXF-7176
             Project: CXF
          Issue Type: Improvement
          Components: JMS
    Affects Versions: 3.1.4
         Environment: SOAP/JMS services (client or server) accessing a Weblogic (10 to 12) JMS Module with a Weblogic Security Strategy
            Reporter: Jérôme Tamborini
            Assignee: Christian Schneider


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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)