[
https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101613#comment-15101613
]
Guillaume commented on CXF-6742:
--------------------------------
The exposeJndiContext is not mandatory in my view, but offered mostly two
things to me : 1) a non regression option if the behaviour had any unintended
effect (making it opt in would prevent that) and 2) make it obvious that there
was something special going on.
I did not perf test this for the outgoing case, because we were in a
"functionnality trumps performance" context : slow is better than KO. And I
guess, if you're really serious about performance anyway, you'll build a pool
of client objects (just as you build a pool of HTTP clients) and hide it behind
some kind of service facade.
Currently, in production, we are creating the initial context just before
instantiating the javax.ws.Service instance, and destroying it after each call,
so, we have no re-use pattern at all. And that's why our main need is mostly
server-side, by the way, because you always have control of which thread sends
a client request, so you can get yourself out of this kind of issue (as long as
CXF does not spawn its own thread to listen for a reply - then it gets
trickier).
We could also have a two step resolution of this issue. Server side first, and
then, have a broader discussion about client side.
> 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)
