Securing the Liberty batch environment

The Liberty batch framework allows you to configure role-based access to all batch management operations and also to view metadata and logs associated with your batch jobs.

Before you begin

Batch roles are defined by the batch container. A single user can have more than one batch role.

batchAdmin: A batchAdmin has unrestricted access to all batch operations. This includes permission to submit new jobs, stop and restart any user's jobs, view any job metadata and job logs that are submitted by any user in the batch domain, and to purge any jobs. A batchAdmin is not necessarily a WebSphere® Application Server administrator.
batchGroupAdmin: If users have the role of batchGroupAdmin and are members of the operation group where the jobs are assigned, they can access all batch operations for those jobs. Users with the batchGroupAdmin role can stop, repeat, restart, and view any job, but they cannot submit new jobs unless they also have the role of batchSubmitter. A batchGroupAdmin user can view job metadata and job logs as well as purge jobs that other users in the same operation group submitted. A batchGroupAdmin user is not necessarily a WebSphere Application Server administrator.
batchSubmitter: A batchSubmitter has permission to submit new jobs and can only perform batch operations such as stop, restart, or purge on their own jobs. A batchSubmitter cannot view or modify other user's jobs. For example, if user1 and user2 are defined as batchSubmitters, and user1 submits a job, user2 cannot view the job instance data that is associated with user1's job.
batchMonitor: Users with the role of batchMonitor have read-only permissions to all jobs. Users in this role can view all job instances and executions and have access to all job logs. Users with the role of batchMonitor cannot submit their own jobs, or stop, restart, or purge any jobs.
batchGroupMonitor: A batchGroupMonitor has read-only permissions for all jobs that are associated with the operation group to which the user belongs. Users in this role can view all job instances and executions, and they have access to all job logs for jobs within the scope of their operation group. A batchGroupMonitor cannot submit, stop, restart, or purge jobs.

Note: Once batch security is enabled, any JobOperator API method or REST operation that returns a list is filtered based on the batch roles that are granted to the current user. For example, when a user with only batchSubmitter permissions requests a list of all job instances, only job instances that are submitted by the current user are returned.

Procedure

By default, the batch-1.0 feature does not enable any security. The JobOperator methods remain open for all users whether they are authenticated or not. The methods remain open for development purposes only and require no security configuration.
The batchManagement-1.0 feature enables the batch REST API. The REST API always requires a user to authenticate even when the appSecurity-2.0 feature is not enabled, but all users are treated as batch administrators and can perform all batch operations on any job instance. Once appSecurity-2.0 is enabled, batch role-based security authorization is performed and users are restricted to batch operations defined by their given batch roles.
1. Enable the batch role-based security through the JobOperator API.
```
<featureManager>
	<feature>batch-1.0</feature>
	<feature>appSecurity-2.0</feature>
</featureManager>
```
2. Enable the batch role-based security through the REST API.
  Note: The batchManagement-1.0 feature includes the batch-1.0 feature.
```
<featureManager>
	<feature>batchManagement-1.0</feature>
	<feature>appSecurity-2.0</feature>
</featureManager>
```

Configure your server.xml file to support role-based security.

The following example illustrates a basic user registry that defines a list of users. This registry is used by sample batch role-based security configurations:

<basicRegistry id="basic" realm="ibm/api">
	<user name="alice" password="alicepwd" />
	<user name="bob" password="bobpwd" />
	<user name="jane" password="janepwd" />
	<user name="joe" password="joepwd" />
	<user name="phyllis" password="phyllispwd" /> 
	<user name="kai" password="kaipwd" />
</basicRegistry>

In this example, one user occupies multiple roles.

<authorization-roles id="com.ibm.ws.batch">
	<security-role name="batchAdmin" >	
		<user name="alice" />	
	</security-role>
	<security-role name="batchSubmitter" >
		<user name="jane" />
		<user name="phyllis" />
		<user name="bob" />
	</security-role>
	<security-role name="batchMonitor" >
		<user name="joe" />
		<user name="bob" />
	</security-role>
</authorization-roles>

In this example, one user occupies multiple roles. All users have the batchSubmitter role.

<authorization-roles id="com.ibm.ws.batch">
	<security-role name="batchAdmin" >	
		<user name="alice" />	
	</security-role>
	<security-role name="batchSubmitter" >
		<special-subject type="ALL_AUTHENTICATED_USERS"/>
	</security-role>
	<security-role name="batchMonitor" >
		<user name="joe" />
		<user name="bob" />
	</security-role>
</authorization-roles>

In this example, one user occupies multiple roles. All users, including those users that are not authenticated, are allowed to have the batchMonitor role.

<authorization-roles id="com.ibm.ws.batch">
	<security-role name="batchAdmin" >	
		<user name="alice" />	
	</security-role>
	<security-role name="batchSubmitter" >
		<user name="joe" />
		<user name="bob" />
	</security-role>
	<security-role name="batchMonitor" >
		<special-subject type="EVERYONE"/>
	</security-role>
</authorization-roles>

Note: If the zosSecurity-1.0 feature is enabled, then batch role-based authorization is handled by the SAF authorization provider.

The SAF authorization provider determines the authorization of the client by checking the client's access level to SAF resource profiles defined in the EJBROLE class. By default, the following resource profiles are associated with the batch roles.

batchAdmin:     BBGZDFLT.com.ibm.ws.batch.batchAdmin
batchSubmitter: BBGZDFLT.com.ibm.ws.batch.batchSubmitter
batchMonitor:   BBGZDFLT.com.ibm.ws.batch.batchMonitor

The client identity must be granted READ access to the appropriate resource profile to be authorized to the corresponding batch role.

The following example illustrates the RACF® commands to grant the client identity, bob, authorization to the batchAdmin role.

RDEFINE EJBROLE BBGZDFLT.com.ibm.ws.batch.batchAdmin UACC(NONE)
PERMIT BBGZDFLT.com.ibm.ws.batch.batchAdmin CLASS(EJBROLE) ID(bob) ACCESS(READ)