You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by William Walsh <WW...@curamsoftware.com> on 2010/04/22 17:08:23 UTC

Differences in WLS security with Axis 1.4 versus Axis2

Is anyone aware of how/why WebLogic is showing us differences between Axis 1.4 and Axis2 in how security is being processed on invocation of a service?

For Axis 1.4 we have our own provider that extends org.apache.axis.providers.java.RPCProvider, which in its invokeMethod method sets up a properties object to create a new InitialContext, calls PortableRemoteObject.narrow, calls the EJB create() method, and then calls invoke on the service method(), which works fine with WLS.

For Axis2 it looks like this same functionality is provided in EJBUtils.java and RPCUtils.java; so, we're extending org.apache.axis2.rpc.receivers.ejb.EJBMessageReceiver and in our invokeBusinessLogic method, for WLS, we just invoke super.invokeBusinessLogic(messageContextIn, messageContextOut), which results in this error:

[ERROR] [EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB: type=<ejb>, application=TestModel, modu
le=FacadeModule.jar, ejb=Axis2DocWebServiceTestBPO, method=simpleAdd, methodInterface=Remote, signature={int,int}.
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:194)
        at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:102)
        at curam.util.connectors.axis2.CuramMessageReceiver.invokeBusinessLogic(CuramMessageReceiver.java:54)
        at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
        at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
        at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
        at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)

The jndiUser and jndiPassword parameters in services.xml and server-config.wsdd are equivalent and are both against same WLS system, same ear, different war files.

I have added  runAs code to our Receiver for the WLS JAAS configuration with some success; but we never had to do this for Axis 1.4.  Any ideas why we are seeing this difference?

Thanks,
William



The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you are not the intended
addressee please contact the sender and dispose of this e-mail. Thank you.

RE: Differences in WLS security with Axis 1.4 versus Axis2

Posted by William Walsh <WW...@curamsoftware.com>.
Hi,  Just to give an update in case it spurs any thoughts or helps anyone in the future.  I've coded a custom receiver that essentially duplicates the Axis2 EJB receiver code (e.g. EJBUtil.java, RPCUtil.java) without the threading and that works for us; that is, we don't fail with the [EJB:010160] error.  So, I'm concluding that the threading used in the EJBUtil class is somehow interfering with WebLogic's normal authentication path.

William


From: William Walsh [mailto:WWalsh@curamsoftware.com]
Sent: Wednesday, May 05, 2010 1:55 AM
To: java-user@axis.apache.org
Subject: RE: Differences in WLS security with Axis 1.4 versus Axis2

Still trying to progress this issue; would appreciate any input/help.

It looks like a threading issue in Axis2 in that there are these calls:
    Our custom receiver code (when WLS) simply calls: super.invokeBusinessLogic(messageContextIn, messageContextOut);
    which then invokes:
      org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(MessageContext, MessageContext)
      org.apache.axis2.receivers.AbstractMessageReceiver.getTheImplementationObject(MessageContext)
        org.apache.axis2.receivers.AbstractMessageReceiver.makeNewServiceObject(MessageContext)
        org.apache.axis2.rpc.receivers.ejb.EJBUtil.makeNewServiceObject(MessageContext)

The call to makeNewServiceObject starts a new (EJBClientWorker) thread that makes the usual RMI/EJB calls (similar to what we do with Axis 1.4); to summarize:
      org.apache.axis2.rpc.receivers.ejb.EJBUtil$EJBClientWorker.createRemoteEJB
        org.apache.axis2.rpc.receivers.ejb.EJBUtil$EJBClientWorker.getEJBHome
          Creates Property object for Context.SECURITY_PRINCIPAL, Context.SECURITY_CREDENTIALS, Context.INITIAL_CONTEXT_FACTORY, & Context.PROVIDER_URL
          org.apache.axis2.rpc.receivers.ejb.EJBUtil.EJBClientWorker.getContext(Properties) - new InitialContext(properties)
          org.apache.axis2.rpc.receivers.ejb.EJBUtil.EJBClientWorker.getEJBHome(InitialContext, String) - context.lookup(beanJndiName)
          Object ehome = javax.rmi.PortableRemoteObject.narrow(ejbHome, cls);
          Method createMethod = cls.getMethod("create", empty_class_array);
          return createMethod.invoke(ehome, empty_object_array);

It appears that from this thread WebLogic does the JAAS authentication, calling our login module's login() method and successfully authenticating; but, then ending the thread and returning back to the RPCMessageReceiver.invokeBusinessLogic() thread where it calls org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(AxisMessage, Method, Object, String, OMElement, MessageContext) that calls java.lang.reflect.Method.invoke(Object, Object...) and then falls over because of the WebLogic error: EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB.

So would this be failing because the create EJB call is where WebLogic is invoking the authentication and it's done in a different thread to the service method invocation and thus WebLogic doesn't see the EJB invocation as authenticated? Any ideas about this; does this analysis seem correct?  Is anyone else successfully using Axis2 with WebLogic and a login module?   Would seem hard to customize this in a general way.

Thanks,
William


From: William Walsh
Sent: Thursday, April 22, 2010 4:08 PM
To: java-user@axis.apache.org
Subject: Differences in WLS security with Axis 1.4 versus Axis2


Is anyone aware of how/why WebLogic is showing us differences between Axis 1.4 and Axis2 in how security is being processed on invocation of a service?

For Axis 1.4 we have our own provider that extends org.apache.axis.providers.java.RPCProvider, which in its invokeMethod method sets up a properties object to create a new InitialContext, calls PortableRemoteObject.narrow, calls the EJB create() method, and then calls invoke on the service method(), which works fine with WLS.

For Axis2 it looks like this same functionality is provided in EJBUtils.java and RPCUtils.java; so, we're extending org.apache.axis2.rpc.receivers.ejb.EJBMessageReceiver and in our invokeBusinessLogic method, for WLS, we just invoke super.invokeBusinessLogic(messageContextIn, messageContextOut), which results in this error:

[ERROR] [EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB: type=<ejb>, application=TestModel, modu
le=FacadeModule.jar, ejb=Axis2DocWebServiceTestBPO, method=simpleAdd, methodInterface=Remote, signature={int,int}.
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:194)
        at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:102)
        at curam.util.connectors.axis2.CuramMessageReceiver.invokeBusinessLogic(CuramMessageReceiver.java:54)
        at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
        at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
        at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
        at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)

The jndiUser and jndiPassword parameters in services.xml and server-config.wsdd are equivalent and are both against same WLS system, same ear, different war files.

I have added  runAs code to our Receiver for the WLS JAAS configuration with some success; but we never had to do this for Axis 1.4.  Any ideas why we are seeing this difference?

Thanks,
William






The information in this email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else

is unauthorized. If you are not the intended recipient, any disclosure,

copying, distribution or any action taken or omitted to be taken in reliance

on it, is prohibited and may be unlawful. If you are not the intended

addressee please contact the sender and dispose of this e-mail. Thank you.


The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you are not the intended
addressee please contact the sender and dispose of this e-mail. Thank you.

RE: Differences in WLS security with Axis 1.4 versus Axis2

Posted by William Walsh <WW...@curamsoftware.com>.
Still trying to progress this issue; would appreciate any input/help.

It looks like a threading issue in Axis2 in that there are these calls:
    Our custom receiver code (when WLS) simply calls: super.invokeBusinessLogic(messageContextIn, messageContextOut);
    which then invokes:
      org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(MessageContext, MessageContext)
      org.apache.axis2.receivers.AbstractMessageReceiver.getTheImplementationObject(MessageContext)
        org.apache.axis2.receivers.AbstractMessageReceiver.makeNewServiceObject(MessageContext)
        org.apache.axis2.rpc.receivers.ejb.EJBUtil.makeNewServiceObject(MessageContext)

The call to makeNewServiceObject starts a new (EJBClientWorker) thread that makes the usual RMI/EJB calls (similar to what we do with Axis 1.4); to summarize:
      org.apache.axis2.rpc.receivers.ejb.EJBUtil$EJBClientWorker.createRemoteEJB
        org.apache.axis2.rpc.receivers.ejb.EJBUtil$EJBClientWorker.getEJBHome
          Creates Property object for Context.SECURITY_PRINCIPAL, Context.SECURITY_CREDENTIALS, Context.INITIAL_CONTEXT_FACTORY, & Context.PROVIDER_URL
          org.apache.axis2.rpc.receivers.ejb.EJBUtil.EJBClientWorker.getContext(Properties) - new InitialContext(properties)
          org.apache.axis2.rpc.receivers.ejb.EJBUtil.EJBClientWorker.getEJBHome(InitialContext, String) - context.lookup(beanJndiName)
          Object ehome = javax.rmi.PortableRemoteObject.narrow(ejbHome, cls);
          Method createMethod = cls.getMethod("create", empty_class_array);
          return createMethod.invoke(ehome, empty_object_array);

It appears that from this thread WebLogic does the JAAS authentication, calling our login module's login() method and successfully authenticating; but, then ending the thread and returning back to the RPCMessageReceiver.invokeBusinessLogic() thread where it calls org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(AxisMessage, Method, Object, String, OMElement, MessageContext) that calls java.lang.reflect.Method.invoke(Object, Object...) and then falls over because of the WebLogic error: EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB.

So would this be failing because the create EJB call is where WebLogic is invoking the authentication and it's done in a different thread to the service method invocation and thus WebLogic doesn't see the EJB invocation as authenticated? Any ideas about this; does this analysis seem correct?  Is anyone else successfully using Axis2 with WebLogic and a login module?   Would seem hard to customize this in a general way.

Thanks,
William


From: William Walsh
Sent: Thursday, April 22, 2010 4:08 PM
To: java-user@axis.apache.org
Subject: Differences in WLS security with Axis 1.4 versus Axis2


Is anyone aware of how/why WebLogic is showing us differences between Axis 1.4 and Axis2 in how security is being processed on invocation of a service?

For Axis 1.4 we have our own provider that extends org.apache.axis.providers.java.RPCProvider, which in its invokeMethod method sets up a properties object to create a new InitialContext, calls PortableRemoteObject.narrow, calls the EJB create() method, and then calls invoke on the service method(), which works fine with WLS.

For Axis2 it looks like this same functionality is provided in EJBUtils.java and RPCUtils.java; so, we're extending org.apache.axis2.rpc.receivers.ejb.EJBMessageReceiver and in our invokeBusinessLogic method, for WLS, we just invoke super.invokeBusinessLogic(messageContextIn, messageContextOut), which results in this error:

[ERROR] [EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB: type=<ejb>, application=TestModel, modu
le=FacadeModule.jar, ejb=Axis2DocWebServiceTestBPO, method=simpleAdd, methodInterface=Remote, signature={int,int}.
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:194)
        at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:102)
        at curam.util.connectors.axis2.CuramMessageReceiver.invokeBusinessLogic(CuramMessageReceiver.java:54)
        at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
        at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
        at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
        at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)

The jndiUser and jndiPassword parameters in services.xml and server-config.wsdd are equivalent and are both against same WLS system, same ear, different war files.

I have added  runAs code to our Receiver for the WLS JAAS configuration with some success; but we never had to do this for Axis 1.4.  Any ideas why we are seeing this difference?

Thanks,
William



The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you are not the intended
addressee please contact the sender and dispose of this e-mail. Thank you.