cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6742) Weblogic Integration for secured JMS Modules
Date Fri, 15 Jan 2016 10:49:39 GMT

    [ 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)

Mime
View raw message