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

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.

About this task

Procedure

  1. 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.
    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>
  2. 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>

Icon that indicates the type of topic Task topic

File name: twlp_batch_securing.html