IC5Notice: We have upgraded developerWorks Community to the latest version of IBM Connections. For more information, read our upgrade FAQ.
  • 1 reply
  • Latest Post - ‏2010-07-14T02:42:23Z by DonBagwell
15 Posts

Pinned topic CWLRB5240E Not authorized for job status when no app security

‏2010-07-13T03:56:11Z |

I have setup a standalone server running Feature Pack for Modern Batch in a WAS V7.0.0.11 server.

The WAS server has administrative security enabled, but at this stage I have NOT enabled application security.

I deployed the SimpleCI.ear sample app, and then I submitted SimpleCIxJCL.xml successfully using the Compute Grid Job Management Console. But when I went to the view jobs option and then clicked on the job that I had submitted I got this error in the SystemOut.log:

13/07/10 13:29:21:656 EST 0000001c JobSchedulerB E CWLRB5220E: Submitter UNAUTHENTICATED is not authorized to perform the output job action on jobId = SimpleCIEar:00004.
13/07/10 13:29:21:671 EST 0000001c RemoteExcepti E CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "getLogMetaData" on bean "BeanId(LongRunningScheduler#LongRunningJobSchedulerEJBs.jar#JobScheduler, null)". Exception data: java.lang.SecurityException: CWLRB5240E: You are not authorized to perform the output job action on job SimpleCIEar:00004. The output job action can only be performed by the Long Running Job administrator or the submitter of job SimpleCIEar:00004 . Please contact the Long Running Job administrator or the submitter of job SimpleCIEar:00004 for assistance.
at com.ibm.ws.batch.JobSchedulerBean.checkCallerAuthorized(JobSchedulerBean.java:140)
at com.ibm.ws.batch.JobSchedulerBean.getLogMetaData(JobSchedulerBean.java:745)
at com.ibm.websphere.longrun.EJSRemoteStatelessJobScheduler_d7897126.getLogMetaData(Unknown Source)
at com.ibm.websphere.longrun._JobScheduler_Stub.getLogMetaData(_JobScheduler_Stub.java:4306)
at com.ibm.ws.batch.jobmanagement.web.actions.ViewJobLogAction.handleRefreshAction(ViewJobLogAction.java:154)
at com.ibm.ws.batch.jobmanagement.web.actions.ViewJobLogAction.execute(ViewJobLogAction.java:98)
at org.apache.struts.action.RequestProcessor.processActionPerform(Unknown Source)
at org.apache.struts.action.RequestProcessor.process(Unknown Source)
at org.apache.struts.action.ActionServlet.process(Unknown Source)
at org.apache.struts.action.ActionServlet.doGet(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1655)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:937)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:500)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:91)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:864)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:455)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:384)
at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:83)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)

I understand the reason in the CWLRB5240E message ( and I know how to resolve it ), but my reason for this post is that since I have not enabled application security, I would not have thought I would get the authorisation exception that has been produced.

In the WAS Admin GUI, if I select Job Scheduler -> Security role to user/group mapping, there are two EJBROLEs: lrsubmitter lradmin - both of which have None as 'Special Subjects' and I have not mapped any userids to these roles.

In redbook: SG247660 WebSphere Application Server V7.0 Security Guide it says this about application security:

Using declarative security means that security policies are configured
independently of the logic of the application code. Security information is
specified using metadata, either through annotations in the application or in the
EJB deployment descriptor. Security is enforced by the application server.
When declarative security is used by any application deployed in the application
server, application security has to be enabled for the run time. However, if
applications rely only on programmatic security, administrators do not
necessarily have to enable application security.

To me there seems to be an inconsistency here, without App security enabled I can access the JMC ( without having to supply a uid and pwd) and submit a job, but I then cannot view the output of my own job. I'd be interested to hear whether the product developers agree whether there is something amiss here, or if this is a case of the Batch Feature code using programmatic security for some parts of the product, and thus not needing application security enabled for it to be in effect.

Also from the WAS V7 Batch Beta infocenter this link:


says in part:

You can secure the job scheduler application by enabling global security.

This seems to me incorrect, since my WAS server has global security enabled, application security disabled, but I can start up a browser, access the JMC admin GUI without supplying any uid and pwd and submit a job. Above line should probably say:

You can secure the job scheduler application by enabling global security and application security.


Edward McCarthy
Updated on 2010-07-14T02:42:23Z at 2010-07-14T02:42:23Z by DonBagwell
  • DonBagwell
    6 Posts

    Re: CWLRB5240E Not authorized for job status when no app security

    Yes, I agree ... I'm a little perplexed by this scenario.

    It seems with "Application Security" off I can access the JMC (or use the lrcmd.sh or RMI client) without authentication. I'm able to submit jobs. With the RMI client the scheduler throws a stack trace complaining about the "UNAUTHENTICATED user" but it allows the job to go in. The batch end point seems to process regardless; that is, no role checking done at all.

    As you say, there's an inconsistency here. The best course of action seems to be to enable application security. That makes the model work according to expectations. But that's a cell-wide setting. Will there be impact elsewhere? Not sure.