WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #87: Batch Roles

By David Follis posted Wed April 22, 2020 07:55 AM

This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.

To start at the beginning, follow the link to the first post.

The next post in the series is here.

This series is also available as a podcast on 
iTunesGoogle PlayStitcher, or use the link to the RSS feed

The ability to submit and manage batch jobs through the REST interface has several layers of security.  The first is simply the ability to make an HTTPS connection to the server and execute under an authenticated identity. 

But after that, what controls access to jobs?  Well, what kinds of things do we need to do?  We want to control who can submit a job, but we also want to control who can look at the results of those jobs and manipulate then (e.g. stop and purge). 

This access is controlled by defining roles in the security configuration for this server.  This can be done directly in the Liberty server configuration itself or externally in another security repository. 

The batch code defines three main roles (plus two more we’ll get to later).  The first role is that of a submitter.  As a user with permission to this role you can, naturally enough, submit jobs.  But it also allows you to look at and control jobs you submit.  That’s important.  A user who submits a job but can’t find out what happened to it will be a frustrated user.  This makes the role of submitter a little special because it has full operational control over its own jobs.  If all your production jobs are submitted by one functional id, that ID has a lot of power over the jobs. 

The second main role is that of monitor.  A monitor essentially has read access to the job information kept in the repository.  A user acting as a monitor can find out the status of jobs, retrieve job logs, and generally look at all the job information.  But a monitor can’t change anything.  They can’t stop a running job or submit or restart jobs.  They just watch.

The final main role is an administrator.  A batch administrator can do all of it.  He can submit jobs.  He can look at job status and job output.  He can stop running jobs and purge old jobs.  Be careful who you grant access to the batch administrator role.

Next time we’ll look at those two other roles I hinted at….