cancel
Showing results for 
Search instead for 
Did you mean: 

PI 7.11 JMS adapter using JNDI weblogic server connection issue

0 Kudos

Dear colleagues, we are facing an issue using PI711 JMS Receiver adapter when accessing Weblogic 10.3.4. (server).

For info: PI 7.11 SP8.

We need to send JMS messages to:
1. Weblogic (10.3.4) Application

So far the drivers deployment includes:

  • Weblogic driver (wlfullclient.jar)

SAPJVM5 is used. We used wlfullclient.jar delivered for JDK 1.5.


We followed the SAP indications for deploying a JMS driver.

The issuefaced is:

Message processing failed. Cause:
com.sap.aii.adapter.jms.api.connector.ConnectorException: Connector for
ConnectionProfile of channel: JMS_Receiveron node: 641513250 having
object id: 577b15909f13373cb166100f7340eaee encountered error: Access
denied to resource: type=<jms>, application=Exposition-JMS-module,
destinationType=queue, resource=<xxxxxxxxx>,
action=send in sending to destination
Exposition-JMS-module.<xxxxxxxxxxx>, the message
message: TextMessage[null, <?xml version="1.0" encoding="...]:
weblogic.jms.common.JMSSecurityException: Access denied to resource:
type=<jms>, application=Exposition-JMS-module,
destinationType=queue, resource=<xxxxxxxxxxxxxxx>,
action=send

where xxxxxxx is the resource name.

The java error met using JNDI is:

javax.naming.NoPermissionException: User <anonymous> does not have permission on StringJndiName to perform modify operation. [Root exception is javax.naming.NoPermissionException: User <anonymous> does not have permission on StringJndiName
to perform modify operation.]

at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:234)

at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:348)

Although credential provided on JMS receiver adapter adapter.

On another hand, Here is what we can notice in XACML logs (on Weblogic server side):

      
1 - When PI sends JMS messages, following objects are not populated: WLSUserImpl, WLSGroupImpl

    
2-  When a Eclipse client sends message, those objects are populated
               Principal = class weblogic.security.principal.WLSUserImpl("weblogic")                    
               Principal = class weblogic.security.principal.WLSGroupImpl("Administrators")


See logs below:

========================================
LOGS Sending message JMS VIA SAP PI
========================================


<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> < Subject: 0>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> < Roles:Anonymous>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> < Resource: type=<jndi>, application=,
path={weblogic,wsee,DefaultQueue}, action=lookup>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> < Direction: ONCE>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> < Context Handler: >
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> <Accessed Subject: Id=urn:oasis:names:tc:xacml:2.0:subject:group, Value=everyone>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> <Evaluate urn:oasis:names:tc:xacml:1.0:function:string-is-in(everyone,everyone) -> true>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> <primary-rule evaluates to Permit>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<urn:bea:xacml:2.0:entitlement:resource:type@E@Fjndi@G, 1.0 evaluates to
Permit>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> <XACML Authorization isAccessAllowed(): returning PERMIT>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<com.bea.common.security.internal.service.AccessDecisionServiceImpl.isAccessAllowed
AccessDecision returned PERMIT>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<com.bea.common.security.internal.service.AuthorizationServiceImpl.isAccessAllowed returning adjudicated: true>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<AuthorizationManager will use common security for ATZ>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<weblogic.security.service.WLSAuthorizationServiceWrapper.isAccessAllowed>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<com.bea.common.security.internal.service.AccessDecisionServiceImpl.isAccessAllowed
Identity=Subject: 0>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<com.bea.common.security.internal.service.AccessDecisionServiceImpl.isAccessAllowed Roles=[ "Anonymous" ]>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<com.bea.common.security.internal.service.AccessDecisionServiceImpl.isAccessAllowed
Resource=type=<jms>, application=TubeJMSModule, destinationType=queue,
resource=TubeXAQueue, action=send>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<com.bea.common.security.internal.service.AccessDecisionServiceImpl.isAccessAllowed
Direction=ONCE>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> <XACML Authorization isAccessAllowed(): input arguments:>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> < Subject: 0>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> < Roles:Anonymous>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> < Resource: type=<jms>,
application=TubeJMSModule, destinationType=queue, resource=TubeXAQueue,
action=send>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> < Direction: ONCE>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> < Context Handler: >
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> <Accessed Subject: Id=urn:oasis:names:tc:xacml:1.0:subject:subject-id,
Value=<empty>>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> <Evaluate urn:oasis:names:tc:xacml:1.0:function:string-is-in(weblogic,<empty>) -> false>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> <primary-rule evaluates to NotApplicable because of Condition>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<urn:bea:xacml:2.0:entitlement:resource:type@E@Fjms@G@M@Oapplication@ETubeJMSModule@M@OdestinationType@Equeue@M@Oresource@ETubeXAQueue,
1.0 evaluates to Deny>

<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000> <XACML Authorization isAccessAllowed(): returning DENY>
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<com.bea.common.security.internal.service.AccessDecisionServiceImpl.isAccessAllowed
AccessDecision returned DENY>
 
<27 mai 2013 19 h 12 CEST> <Debug> <SecurityAtz> <BEA-000000>
<com.bea.common.security.internal.service.AuthorizationServiceImpl.isAccessAllowed
returning adjudicated: false>

Thank you in advance for your help.

Christophe.

Accepted Solutions (1)

Accepted Solutions (1)

Bhargavakrishna
Active Contributor
0 Kudos

HI Anandh,

As said by muniyappan, there may be some authentication issue.

The issuefaced is:

Message processing failed. Cause:
com.sap.aii.adapter.jms.api.connector.ConnectorException: Connector for
ConnectionProfile of channel: JMS_Receiveron node: 641513250 having
object id: 577b15909f13373cb166100f7340eaee encountered error: Access
denied to resource:

Refer below link for the same issue

http://scn.sap.com/thread/877748

For javax.naming.NoPermissionException: User <anonymous> does not have permission on StringJndiName to perform modify operation. [Root exception is javax.naming.NoPermissionException: User <anonymous> does not have permission on StringJndiName
to perform modify operation.]

Remove the current role and give the admin credentials.. it should work..

Refer below link

http://weblogic-wonders.com/weblogic/2010/06/14/securing-the-jndi-with-admin-role-in-11g/

Regards

Bhargava krishna

0 Kudos

Dear Bhargava, Thank you for you inputs but the issue persists.

What we detect (using xi_pi inspector) is that credentials are correctly send to Weblogic when starting the JMS adapter, but NOT when sending messages.

I wonder if it is a known bug or if thete is a particular configuration for sending credential when sending messages.

Let me know if you have some ideas. Kind regards. Christophe.

Bhargavakrishna
Active Contributor
0 Kudos

Hi Bhargava,

after a deeper analysis of xpi_inspector tarces, we found that on starting JMS receiver adapter,

using JNDI,

1. createInitialContext is called,

2. build connection,

3. build session

4. Create destination

Then connection start successfull

Immediately after, a closeInitialContext is called.

The error "Catching weblogic.jms.common.JMSSecurityException: Access denied to resource"

comes on sending the queue, without context opened (when security is activated).

We found that Weblogic needs to maintain the JNDI context in a thread in order to check autorisation on JNDI ressources and so JMS ressources.

See the link: http://flylib.com/books/en/2.107.1.35/1/  . (4.1.2 Security in a Context)

I let you know when I have more inputs.

All solution or work around welcome for sure. Christophe.

Bhargavakrishna
Active Contributor
0 Kudos

Hi christophe,

thanks for the update..

Refer below link, it may help you to maintain weblogic in JNDI context.

http://docs.oracle.com/cd/E15051_01/wls/docs103/jndi/jndi.html

http://scn.sap.com/thread/1548834

http://scn.sap.com/message/5570578

http://weblogic-wonders.com/weblogic/2011/02/01/securing-weblogic-jms-resources/

Hope it will helpful..

Regards

Bhargava krishna

0 Kudos

Dear All, Thanks for participating. Here here the last findings we have:

1.The class removal under javax/jms in the wlfullclient.jar are necessary because other classloader errors could occur. It is mandatory to remove everything under javax/jms.

2.From the XPI Inspector traces in starting and stopping the channel, it connects to the Weblogic Server and to the queue successfully.


According to Weblogic Documentation when you create a JNDI Initial Context with a username and password, you associate a user with a thread. Before starting a new Context on the thread, you must close the first Context so that the first user is no longer associated with the thread. Otherwise, users are pushed down in the stack each time a new context is created.

This is not an efficient use of resources and may result in the incorrect user being returned by ctx.lookup() calls.
This is the reason why we close the Initial Context after a successful connection. But according to this documentation the security scope ends with a context.close() method.

There is a flag weblogic.jndi.enableDefaultUser. If this flag is enabled  even after a ontext.close() the current user is not removed from the thread context.

The solution is to  add this flag in the JMS Receiver channel configuration.

JNDI.InitialContext.property.5 =
java.lang.String weblogic.jndi.enableDefaultUser, java.lang.String true

Thanks for your attention.

Answers (1)

Answers (1)

Muniyappan
Active Contributor
0 Kudos

Hi Chris,

it seems to be an issue with username and password you are using to connect to weblogic.

can you check your credential with weblogic team?

Regards,

Muniyappan.