WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #89: Batch Application Security

By David Follis posted Wed May 06, 2020 08:03 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

When a batch job runs in a Liberty server there is an identity associated with the thread running the application.  That identity is the same identity as the user who submitted the job.  If the REST interface was used to submit the job, that means the identity that authenticated over the HTTPS connection will be the identity used to execute the job.

That identity is probably some functional id used by an enterprise scheduler to submit every job.  That identity probably does not have access to all the resources needed by the job.  How can we get around this?

Well, it depends on the type of resource the job is trying to access.  Database access done through a datasource definition in the server configuration can often include access credentials in the configuration to be used instead of the identity running the application.  This works just the same for batch applications as it does for any other application in Liberty.

In some cases, the application identity is used, but the submitter’s identity is the wrong one.  In these cases, it might be possible to define a RunAs identity for the application.  This is a Java EE security concept that allows, as part of the application packaging and server configuration, the specification of an identity to be used to run the application that isn’t the identity that submitted the job.  You can do this sort of thing with non-batch applications deployed in Liberty.  The same thing works for batch applications.

Other resources might use the server identity, ignoring the identity running the application.  In some cases, these are operating system controlled resources (i.e. a z/OS dataset).  The identity of the server itself will be used to grant or deny access. 

If that’s the wrong identity, it might be possible to configure the server and application to perform what is called ‘sync to OS thread’.  This causes the server to take the identity running the application and ‘push’ it down onto the native operating system thread that is underneath the Java thread.  In some cases, the OS or other system resources will honor this native-thread identity in preference to the identity of the server itself.

There’s clearly a lot more to this.  Hopefully I’ve given you some hints to follow in solving whatever your particular problem might be.