on 05-29-2013 1:41 PM
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:
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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.
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
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
25 | |
12 | |
9 | |
6 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.