[
https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume updated CXF-6742:
---------------------------
Attachment: soapJMSWeblo.diff
The building blocks of this patch are :
Configuration
1) Add a boolean "exposeJndiEnvironment" internal variable to the JMSEndpoint
class, allowing a separate trigger for the new behavior. This makes this
boolean settable inside a jms:jndi URL inside an endpoint description.
2) Mirror this property inside the JMSConfig object, to carry it on the rest of
the framework
3) Make the JMSConfigFactory copy the property from step1 above to step 2
Server side SOAP/JMS
1) Make the JMSDestination object honor the "exposeJndiEnvironment" flag, by
progpagating the JNDI environment from the JMSConfig to the
MessageListenerContainer
2) Enhance AbstractMessageListenerContainer to be able to hold this
JndiEnvironment, expose it as an InitialContext, and close it
3) Inside the PollingMessageListenerContainer, detect the presence of this
JNDIEnvironment, and if available, wrap the Poller/XAPoller runnables inside a
new JNDIPollerDecorator to actually call the methods at step 2 above
Client side
1) Make the JMSConduit honor JMSConfig's "exposeJNDIContext" flag at the start
of the sendExchange method
2) Make it propagate the environment to the conduit's MessageListernerContainer
(same base class as the server side)
3) Make MessageListenerContainer honor the new behavior : there's actually
nothing to do here because the current implementation does not spawn threads,
but a javadoc is added to remember that if ever this would change.
About this patch : well first, I'm not a seasonned CXF hacker, so my knowledge
of its coding convetions is limited.
Second, I did not refactor the JNDIHelper class in this, but this might reduce
boilerplate code if done elegantly.
Finally, I do not know the unit test infrastructure well enough to provide a
basic test for this, but I guess this is weblogic dependant, and not so much
unit testable as "integration" testable.
> 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
> 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)
