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 iTunes, Google Play, Stitcher, or use the link to the RSS feed.
-----
Last time we talked about the submitter, batch monitor, and batch administrator roles that can be used to control access to operational control of and information about Liberty batch jobs. It might have struck you that monitor access is nice, but read access to every job in the system might be a bit much. And an administrator really just has way too much power. It would be nice if there was a way to scope that power to a subset of the jobs.
To do that, we’ll first need to find a way to identify subsets of jobs and indicate who should have control of them. Suppose we have a whole bunch of executor servers hosting many different applications. Some servers host one application, some host several related applications. Since they are grouped by application (more or less) that’s probably how we’ll create groups of access. There are probably groups of developers or operations people that need access (read or write) to things related to certain applications but not to others.
To specify this in the configuration, as part of the jmsBatchExecutor configuration you can specify a list of security group names. These are the groups that have a reason to need access to jobs handled by this executor. Remember that the jmsBatchExecutor element points to an activation specification which can include a message selector string that can limit which application jobs execute in this server. So the control of which-applications is tied to the specification of which-groups need access.
But what access? Some groups might need just read access, such as a developer needing to look at a log. But other groups might need more, such as an operations staff needing to purge or restart a failed job.
To support this, two additional roles are defined: batchGroupAdmin and batchGroupMonitor. If a user is allowed to be in the batchGroupMonitor role AND is a member of a group associated with job (from the executor configuration) then that user can have batch monitor access to the job. But users who are not connected to that group (i.e. in a different development department) won’t be able to look at jobs associated with different departmental groups.
Similarly access to the batchGroupAdmin role allows administrator access, but only to jobs associated with groups that user is a member of.
Careful use of these two additional roles can allow more access to those who need it, without opening the doors to everything.