cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <>
Subject [jira] [Commented] (CXF-6742) Weblogic Integration for secured JMS Modules
Date Thu, 14 Jan 2016 16:00:42 GMT


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?

> Weblogic Integration for secured JMS Modules
> --------------------------------------------
>                 Key: CXF-6742
>                 URL:
>             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 :
> 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 :
> 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
> 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(
>    ...
>    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 :
> 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