cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume (JIRA)" <>
Subject [jira] [Created] (CXF-6742) Weblogic Integration for secured JMS Modules
Date Tue, 12 Jan 2016 14:58:39 GMT
Guillaume created CXF-6742:

             Summary: Weblogic Integration for secured JMS Modules
                 Key: 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

This is a follow up of the user list thread :

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
This is documented here :

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=...

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 :

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
. 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

View raw message