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
Three 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.
- 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
- A batchMonitor has read-only permissions to all jobs. Users in this role can
view all job instances and executions and have access to all job logs. A
batchMonitor cannot submit their own jobs, or stop, restart, or purge any
jobs.
Note: Once batch security is enabled, any JobOperator API method or REST operation
that returns a list will be filtered based on the batch roles granted to the current
user. For example, when a user with only batchSubmitter permissions requests a list
of all job instances, only job instances submitted by the current user will be
returned.
Procedure
- By default, the batch-1.0 feature does not enable any
security. The JobOperator methods are left open for all users whether they are
authenticated or not. The methods are left 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 will
be 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 will be performed and users will be 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
below.
<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>