Modern Java-based batching in WebSphere application Server (v)

Protection Job Scheduler

Brief introduction

IBM WebSphere Application Server V8.5 and later provides a platform for Java-based batch processing applications. Combined with rich programming models and numerous complex features, such as skipping records processing, parallel processing, retry step processing, COBOL support, and integration with Enterprise Scheduler, it also provides enterprise-level quality, namely:

Availability of

Recoverability

Scalability and performance

Security.

For the execution of a batch program, the job scheduler accepts job submissions and determines where they are run. As part of the work of the management job, the job scheduler persists the job information in an external job database. Because Job scheduler is the "threshold" of batch processing job, the protection of job can be realized by the security mechanism of job scheduler. Because batch programs typically handle important, sensitive information, it is critical for them to have high security standards. This article discusses how to secure a WebSphere Batch solution.

A security model for WebSphere Batch

The security of the WebSphere Batch attribute can be managed through the following models:

Role

Security is provided by using this predefined set of roles, which are provided in the WebSphere application Server for batch processing:

Lradmin: The user assigned to this role has the right to perform all operations related to the job scheduler on all jobs, regardless of who owned the job.

Lrsubmitter: The user in this role has the right to perform all operations related to the job scheduler on all jobs owned by the submitter.

Lrmonitor: These users can only view the jobs and job logs for all users.

Group
In the group security model, all job-related security decisions are based only on group membership. A user can complete an action on the job only if the user and the job are members of the same group. For example, if two or more users are members of the same group, and each user submits one assignment to the same group job, all of them can view and process each other's jobs. This occurs because WebSphere application Server performs a group-based check on the job scheduler operation.

Combinations of roles and groups
In this security model that combines groups and roles, the group member relationship and the role all prescribe job security. This means that a user can perform a job operation only if the user and job are members of the same group, and the user's role has permission to perform job-related operations.

For example, if two or more users are members of the same group, and each user submits a job assigned to that group, then all users can view each other's jobs and perform actions-but are constrained by their job assignments:

Users in the Lradmin role can view the jobs of all group members and perform job operations.

Users in the Lrsubmitter role can view only the jobs they submit and perform job operations.

Users in the Lrmonitor role prohibit the submission of jobs, but allow viewing of jobs submitted by other users in the Lradmin and lrsubmitter roles.

With a basic understanding of job scheduler security, we try to harden these concepts with examples that use a variety of security roles, including users, roles, and groups, as shown in tables 1 and 2.

To test, we created the required users and groups using IBM Tivoli Directory Server V6.3 as the LDAP repository. (LDIF script files that are used to create these users and groups are available from the downloads section of this article.) Then, we configured the WebSphere application server for this Tivoli Directory server so that the job scheduler could take advantage of the users and groups that we created. Note that you must configure the Tivoli Directory Server repository as a chain repository, even if the WebSphere application server configuration uses only a single repository.

The following is a brief description of the configuration steps.

Create users and Groups in Tivoli Directory Server

Create the root entry dc=mydw,dc=org of the directory tree. To create it, you can use the Tivoli Directory Server Instance Administration Tool. Click Manage > Manage suffixes.

Enter the suffix dc=mydw,dc=org and click Add, and then click OK (Figure 1).

Figure 1. Create a new suffix in Tivoli Directory Server