Job manager security

In a flexible management environment, a user ID must have the required authorization to use the job manager and to work with registered nodes.


Required security roles

You need the following roles to use the job manager:

Administrative tasks Required security roles
Register or unregister with the job manager administrator
Submit a job operator
Change the job manager configuration configurator
Read the job manager configuration or job history monitor

If base (stand-alone) application server nodes managed by an administrative agent are registered to a job manager, we need the following roles to use the administrative agent and manage its nodes:

security roles for administrative agent tasks. Roles
Administrative tasks Required security roles
Register or unregister a base (stand-alone) node with the administrative agent administrator
Work with the administrative agent: Administrative roles required for the operation being performed
Work with the administrative subsystem, such as registered nodes Administrative roles required for the registered base node

When a job runs on a target, the user must have privileges that include the role required for that job. For example, a job to create an application server requires a minimum configurator role on either the base node or WebSphere Application Server Network Deployment cell.


Security for Installation Manager or Liberty profile jobs on remote hosts

When access to a remote host such as an Installation Manager or Liberty profile requires a user name and password, provide a valid operating system user name and password for a job to run on the remote host. We can provide the following types of authorization:

Operating system user name and password

The user name and password are the login values for the host. If the host does not require a password, then we do not need to provide a password when submitting a job.

Sudo

If we want a substitute user to perform commands on the host, we can use sudo to change users before a job runs, and then specify the user name and password for the substitute user as needed. sudo means "substitute user do". If the host does not require a password, then we do not need to provide a password when submitting a job.

Public-private key authentication

We can use public-private key authentication. When submitting a job, specified the full path to the keystore and, if required for the keystore, the passphrase. A Secure Shell (SSH) private key enables an administrator to run a job at the remote host under a specific user name. The key is password encrypted to prevent use by a different user.

For Liberty profile servers, the type of authorization that you use depends upon the user names configured for each host:

Single user name

If each host uses only one user name, then you only must ensure that the directories to install Liberty profile resources are writable by the user. To support job submission to different hosts, ensure that the same user name is configured on each host or use an SSH key to authenticate as a different user name for each host.

Switching to single user name

If hosts support multiple user names, we can submit jobs under different user names, but use sudo to switch to a single common user name. Only the common user name can manage Liberty profile resources. Often this user name is configured to disable login.

Different user names

In some configurations, we can install each Liberty profile resource under a different operating system user name. For example, shared resources might be installed under one or more user names, and made globally read only, or read-only to a specific operating system group. Non-shared working resources might be created exclusively for different user names.

We can control who can install Liberty profile resources by controlling the file permissions of the root directory for each resource. If we set the directory to be writable by only one user, then only one user can install to that directory. If we set the directory to be writable by a group of users, then users belonging to that group can install resources under the root directory. If we set the directory to be globally writable, then any user can install to that directory.

During installation, we can set file permissions that prevent other users from modifying the resources. For example, we can pre-create ${WLP_WORKING_DIR}/project1 with file permissions such that it is only writable by a specific user, or a specific group. After the user installs a new Liberty profile, such as server1, we can configure ${WLP_WORKING_DIR}/project1/server1 such that it cannot be changed by a different user.

When multiple users can access resources, set variables or job parameters that enable an inventory job to find all available resources:

  • We must define the WLP_ADDITIONAL_DIRS variable so that all relevant paths are searched for resources; or

  • We must ensure that all resources are readable by the user name used to run the inventory job. The resources must be created globally readable, the resources must be operating system group readable with the user name belonging to the group, or the root user name must be used to run the inventory job.


Basic security configuration

The administrative agent and job manager support two different basic security configurations:

For the administrative agent topology, when a user logs in to the JMX connector port of an administrative subsystem, or chooses the registered node from the console, the authorization table for the base node is used.

For example, suppose User1 is authorized as administrator for the first base node, but is not authorized for the second node. User2 is authorized as configurator for the second node, but is not authorized for the first node. The Same user registry figure illustrates this example:

Further suppose User1 can log in to job manager as an operator with a user name and password. User1 can also log in to the deployment manager as a monitor with a user name and password. The Different user registry figure illustrates this example:

Although User1 has the same user name for both the job manager and the deployment manager, User1 might as likely have different user names and passwords.


Transfer of security information

When the product transfers a job from the job manager to the administrative agent, deployment manager or host computer, the product also transfers security information about the job submitter. This transfer authenticates and authorizes the user while running the job. The following user security information might be passed with a submitted job:


Mixed registries configuration

In a more complex topology, where some cells share the same user registry and some cell do not, the following rules apply:


Related concepts

  • Job manager
  • Administrative agent


    Related tasks

  • Administrative roles
  • Administer nodes remotely using the job manager
  • Administer jobs in a flexible management environment
  • Administer nodes and resources
  • Task overview: Securing resources