[
https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15098300#comment-15098300
]
Christian Schneider commented on CXF-6742:
------------------------------------------
Do you think we really need the exposeJndiEnvironment attribute. Would it hurt
to always expose the JNDI environment in worker threads?
> Weblogic Integration for secured JMS Modules
> --------------------------------------------
>
> Key: CXF-6742
> URL: https://issues.apache.org/jira/browse/CXF-6742
> 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: Guillaume
> Assignee: Christian Schneider
> Attachments: soapJMSWeblo.diff
>
>
> 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)
