cxf-issues mailing list archives

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

    [ https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101553#comment-15101553
] 

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?
Edit: I thought about this .. As for example in JMSConduit the JNDI context is established
per message this can have a serious performance impact. So I think we need this config.
On the other hand the performance impact may also be a problem for you. Did you do any performance
tests of secured vs unsecured?

> 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