[
https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179670#comment-15179670
]
Guillaume edited comment on CXF-6742 at 3/4/16 10:16 AM:
---------------------------------------------------------
I Christian, sorry it took me so long, I actually tested a while ago and forgot
to comment.
I can confirm your suggested patch works in my context, on WLS 11 and 12, so it
really is fine.
For now, I don't have a library-level need for SOAP/JMS on the client side (I
can get around whatever securisation I encounter by logging my context before
sending the request throug the CXF layer). There might be a difficulty in
getting an answer back (if the response polling mecanism lives in its own
thread), but I do not have such a setup right now.
If this patch could make it into 3.2.0, that would be great for us.
was (Author: gueugaie):
I Christian, sorry it took me so long, I actually tested a while ago and forgot
to comment.
I can confirm your suggested patch works in my context, on WLS 11 and 12, so it
really is fine.
For now, I don't have a library-level need for SOAP/JMS on the client side (I
can get around whatever securisation I encounter by logging my context before
sending the request througr the CXF layer). There might be a difficulty in
getting an answer back (if the response polling mecanism lives in its own
thread), but I do not have such a setup right now.
If this patch could make it into 3.2.0, that would be great for us.
> 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)
