[jira] [Resolved] (CXF-6742) Weblogic Integration for secured JMS Modules

["Christian Schneider (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Schneider resolved CXF-6742.
--------------------------------------
    Resolution: Fixed

I am resolving this issue as the server side is solved. Please open another issue if we should work on the client side too.

> 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.15#6346)