cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jérôme Tamborini (JIRA) <j...@apache.org>
Subject [jira] [Created] (CXF-7176) CLONE - Weblogic Integration for secured JMS Modules
Date Mon, 12 Dec 2016 09:16:58 GMT
Jérôme Tamborini created CXF-7176:
-------------------------------------

             Summary: CLONE - Weblogic Integration for secured JMS Modules
                 Key: CXF-7176
                 URL: https://issues.apache.org/jira/browse/CXF-7176
             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: Jérôme Tamborini
            Assignee: Christian Schneider


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