Job manager security
When performing a job manager registration process there are a number of WAS security impacts to consider.
In WAS v7, a new style of system management called flexible management was introduced. It differs from the existing style of synchronous invocation and response calls through wsadmin or Java APIs by offering an asynchronous job queuing mechanism for administration purposes. At the core of flexible management is a new administrative process called the job manager. We can make both application servers registered to administrative agents and deployment manager servers known to the job manager through a registration process. After you register the servers, we can queue administrative jobs directed at the application servers or deployment managers through the job manager. We can submit these jobs to a large number of servers over a geographically dispersed area. There are a number of security considerations you must keep in mind both during and after the job manager registration process.
Consider the following:
- Security configuration requirements should be kept to a minimum prior to registration.
- Allow an agent or a deployment manager (dmgr) to be federated to the job manager with almost any security configuration. Some exceptions include:
- The administrative agent or deployment manager must have the same administrative security state (either enabled or disabled).
- To enable security after federation, enable all administrative agent and deployment manager processes within the same administrative domain, then restart all of the processes at the same time.
- Leverage the creation of a chained certificate to exchange only the long-lived root certificates between an administrative agent, deployment manager and job manager. When a personal certificate expires in either the administrative agent, deployment manager or the job manager, it does not affect trust that was established during federation.
- Use the RSA certificate administrative-specific authentication mechanism, which does not rely on shared keys and is the default administrative authentication mechanism for the job manager. The RSA token authentication mechanism is also new to this release of WAS. Read about RSA token authentication mechanism for more information.
- Add a profile Universal Unique Identifier (UUID) to all certificates generated in WAS v8.0. This profile UUID is used to authorize requests to extract jobs from the job manager queue.
- Job Manager jobs can be associated with caller credentials: either LTPA or Kerberos, or with specified credentials using a user ID and password). Both are stored with the job. The password is obfuscated using the standard utilities and can be encrypted when the password encryption plug point is enabled. LTPA and Kerberos are refreshed as long as the authentication mechanism allows them to be refreshed.
- (zos) Job Manager jobs can be associated with caller credentials: either LTPA or with specified credentials using a user ID and password. Both are stored with the job. The password is obfuscated using the standard utilities and can be encrypted when the password encryption plug point is enabled. LTPA is refreshed as long as the authentication mechanism allows it to be refreshed.
- (zos) With this service release, Job Manager jobs can be associated with caller credentials: either Lightweight Third-Party Authentication (LTPA) or Kerberos, or with specified credentials using a user ID and password). Both are stored with the job. The password is obfuscated using the standard utilities and can be encrypted when the password encryption plug point is enabled. LTPA and Kerberos are refreshed as long as the authentication mechanism allows them to be refreshed.
- Administrative agent or deployment manager access to FileTransferServlet is performed by sending a valid RSA certificate that is trusted by the job manager and is validated by CertPath.
The required administrative roles for executing flexible management jobs are defined by the underlying administrative commands used by those jobs. For example, the required role for starting and stopping servers is the operator role. The operator role is also required for execution of the flexible management jobs that start and stop servers. The general rules for assigning required administrative roles are:
- View data requires the monitor role.
- Updating data requires the configurator role.
- Manage jobs requires the operator role.
- Registering or un-registering managed nodes requires the administrator role.
Related concepts
RSA token authentication mechanism LTPA> Kerberos (KRB5) authentication mechanism support for security Job manager Job manager settings
Related tasks
Configure the RSA token authentication mechanism Configure administrative authentication Administer nodes remotely using the job manager Configure job managers
Administrative roles Job status collection