Calling secure EJB from Servlet results: Client not authorized for this invocation.

[glassfishrobot]

Let's assume the following scenario: I have two enterprise applications one contains some EJB and offers its services via remote interface. The other contains a web interface with a servlet and would use some of the EJB services provided by the previous application. As we are using remote interfaces we would like to make the EJB call secure and restricted. By standard it can be defined for a servlet to Run As a role specified in the container. In this case Glassfish V2 throws an

javax.ejb.AccessLocalException: Client not authorized for this invocation.

This issue has been mentioned once: java.net forums http://forums.java.net/jive/thread.jspa?threadID=28602

I'm going to attach NetBeans 6.0 RC2 based project to demonstrate this issue.

Environment

Operating System: All Platform: Linux

Affected Versions

[9.1pe]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/3873
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @vbkumarjayanti
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented lkishalmi said: Created an attachment (id=1275) Simple projects to demonstrate this issue.

[glassfishrobot]

@glassfishrobot Commented lkishalmi said: org.omg.CORBA.NO_PERMISSION: ----------BEGIN server-side stack trace---------- org.omg.CORBA.NO_PERMISSION: vmcid: 0x2000 minor code: 1806 completed: Maybe at com.sun.enterprise.iiop.POAProtocolMgr.mapException(POAProtocolMgr.java:223) at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1386) at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316) at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:210) at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:77) at $Proxy66.sayHello(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:154) at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:687) at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:227) at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1846) at com.sun.corba.ee.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:183) at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:219) at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:192) at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152) at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225) at backend.HelloSessionRemote_Remote_DynamicStub.sayHello(backend/HelloSessionRemote_Remote_DynamicStub.java) at backend._HelloSessionRemote_Wrapper.sayHello(backend/_HelloSessionRemote_Wrapper.java) at frontend.HelloServlet.processRequest(HelloServlet.java:40) at frontend.HelloServlet.doGet(HelloServlet.java:56) at javax.servlet.http.HttpServlet.service(HttpServlet.java:718) at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:270) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:339) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:212) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106) Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation. at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1218) at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:202) ... 52 more ---------END server-side stack trace--------- vmcid: 0x2000 minor code: 1806 completed: Maybe at backend._HelloSessionRemote_Wrapper.sayHello(backend/_HelloSessionRemote_Wrapper.java) at frontend.HelloServlet.processRequest(HelloServlet.java:40) at frontend.HelloServlet.doGet(HelloServlet.java:56) at javax.servlet.http.HttpServlet.service(HttpServlet.java:718) at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:270) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:339) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:212) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)

[glassfishrobot]

@glassfishrobot Commented lkishalmi said: The sample projects require an user named "myboss" in the file realm who belongs to the "BOSS_GROUP". I think the password is not relevant.

It shall be accessible at: http://localhost:8080/FrontendApplication-war/HelloServlet using default GF configuration.

[glassfishrobot]

@glassfishrobot Commented raharsha said: When runAs is specified , the loginPrincipal method of LoginContextDriver is not adding the groups to the principal set.

We have a fix, and will checkin if approved to the UR1 branch.

[glassfishrobot]

@glassfishrobot Commented basler said: Not a 91ur1 release stopper, but should go into 9.1.1

[glassfishrobot]

@glassfishrobot Commented basler said: Change to proper priority

[glassfishrobot]

@glassfishrobot Commented lkishalmi said: We really would like to see this fix in UR1, as we are running a pilot project migrating a company wide management system (used by 2000+ user) from BEA WebLogic to Glassfish. With this bug in We might have to give up our Glassfish plans.

[glassfishrobot]

@glassfishrobot Commented shreedhar_ganapathy said: Hi lkishalmi We certainly would like to help you. For UR1 though we have completed our final build that has to go through a series of QE certification tests in order to be certified as production ready for customers. We are also working with a number of customers who are expecting this release by the published timeframe.

That said, let me send you an email offline to find ways to solve your problem.

Thanks Shreedhar

[glassfishrobot]

@glassfishrobot Commented lkishalmi said: At the time of writing I thought that UR1 was scheduled for January 2008. As GF is open source I also tried to fix the LoginContextDriver. However I was able to add the groups, which were really missing, as PrincipalImpl to the Subject I still get the same error.

[glassfishrobot]

@glassfishrobot Commented lkishalmi said: I just find out that adding groups as Group instead of PrincipalImpl made the things work.

[glassfishrobot]

@glassfishrobot Commented lkishalmi said: Is the fix going to be in GF 2.1? I haven't seen it on the lists at http://wiki.glassfish.java.net/Wiki.jsp?page=PlanForGlassFishV2.1 which is really sad as the fix of this issue is pretty easy (at source code level), but without it I cannot really state that GF is really Java EE compliant.

[glassfishrobot]

@glassfishrobot Commented @vbkumarjayanti said: A Partial Fix which works when the Servlet and EJB are co-located has been integrated into 9.1.1

[glassfishrobot]

@glassfishrobot Commented dcam said: But what about when the web and the EJB are not in the same glassfish instance (not co-located)?

I see a similar situation where I have two glassfish instances, one hosting EJB and the other hosting just WEB but talking to the other for EJB services (even without Run As).

The glassfish instance hosting the EJBs is getting the call and is doing a GSSUP logon, but logs the ProtectionDomain as (principals com.sun.enterprise.deployment.PrincipalImpl "rto"), ie lacking any com.sun.enterprise.deployment.Group which means that it has none of the roles and can't call protected methods.

More detail - the replyer at this forum entry referenced this bug: http://forums.java.net/jive/thread.jspa?threadID=47148&tstart=0

[glassfishrobot]

@glassfishrobot Commented dcam said: Created an attachment (id=1845) rough patch for com.sun.enterprise.security.auth.LoginContextDriver that does seem to solve this issue

[glassfishrobot]

@glassfishrobot Commented harpreet said: Approving for v2.1 - based on feedback from security team.

[glassfishrobot]

@glassfishrobot Commented dcam said: Adding myself as CC

[glassfishrobot]

@glassfishrobot Commented @vbkumarjayanti said: Thanks dcam for the patch, we will look into it and try to fix for V2.1

[glassfishrobot]

@glassfishrobot Commented venu said: I think this has been fixed in latest build and can you give it a try and let us know I will look at your fix. https://sailfin.dev.java.net/downloads/download_os.html

[glassfishrobot]

@glassfishrobot Commented @vbkumarjayanti said: Fixed.

[glassfishrobot]

@glassfishrobot Commented dcam said: Unfortunately I am unable to test right now because the split system is occupied with QA, but I have looked at your code changes at:

http://fisheye5.atlassian.com/browse/~author=venu/glassfish/appserv-core/src/java/com/sun/enterprise/security/auth/LoginContextDriver.java?r1=1.11.6.2&r2=1.11.6.3 http://fisheye5.atlassian.com/browse/~author=venu/glassfish/appserv-core/src/java/com/sun/enterprise/security/auth/LoginContextDriver.java

...and yes I believe you've hit it on the head.

[glassfishrobot]

@glassfishrobot Commented baelene said: I've tested CallerTest application with glassfish 2.1-b60f and I still have the issue.

[glassfishrobot]

@glassfishrobot Commented nitkal said: On analyzing the CallerTest application (Sample application attached with this issue in the beginning), it appears the the security-role-mapping element is missing in the EJB. This can be configured by either attaching a sun-ejb-jar.xml with this entry:

BOSS BOSS

or activating the Default P2R (Principal to Role) mapping in GF through the admin console.

Since the default realm is FileRealm (and because the application does not seem to contain a specific realm), a file user who belongs to the group (which is the group to which the EJB user role is mapped to (viz) BOSS, has to be created.

Though the servlet passes the credentials to the EJB, only when a corresponding role-group mapping is present for the EJB (either through the sun-ejb-jar.xml or Default P2R mapping), access would be granted. Following the above steps should address the issue reported.

[glassfishrobot]

@glassfishrobot Commented @vbkumarjayanti said: Marking the issue as resolved with the last clarification.

[glassfishrobot]

@glassfishrobot Commented File: CallerTest.zip Attached By: lkishalmi

[glassfishrobot]

@glassfishrobot Commented File: patchfile Attached By: dcam

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-3873

[glassfishrobot]

@glassfishrobot Commented Reported by lkishalmi

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Wednesday, September 2nd 2009, 5:46:32 pm