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)
