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.
-
Enable the batch role-based security through the JobOperator API.
<featureManager>
<feature>batch-1.0</feature>
<feature>appSecurity-2.0</feature>
</featureManager>
-
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)