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
We need the following roles to use the job manager:
Required security roles for job manager tasks
| 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:
Required security roles for administrative agent tasks
| 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 jobs on remote hosts
When access to a remote host such as an Installation Manager or Liberty 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
- To have a substitute user to perform commands on the host, we can use sudo to change users
before a job runs.
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
- Use public-private key authentication. When submitting a job, we specify 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 servers, the type of authorization that we use depends upon the user names that are configured for each host:
- Single user name
- If each host uses only one user name, then we only must ensure that the directories to install Liberty 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 resources. Often this user name is configured to disable login.
- Different user names
- In some configurations, we can install each Liberty
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 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, 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, we must 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:
- Same security domain
In this configuration, all the cells in the topology share the same user registry, and therefore, the same security domain. The same is true of the administrative agent and its registered base nodes, and also any job manager or WAS ND cells in the topology.
- Different security domains
In this configuration, all the cells are configured with different user registries, and therefore different security domains.
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 administrative 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:
- User name and password
When submitting a job, the user might specify a user name and password. When the job reaches the administrative subsystem or the deployment manager, the user name and password are used to log in.
For the same user registry configuration, if John submits a job against the first base node, he can specify his user name and password as part of the job. The user name and password are used to log in against the first administrative subsystem, and the job runs. If John submits a job against the deployment manager cell or the second base node, the job fails because John is not authorized.
For the different user registry configuration, John can submit a job against the deployment manager cell, specifying his user name and password for the deployment manager cell. When the job reaches the deployment manager, login succeeds, and the job runs. If John submits a job against the base nodes, access is denied, and the job fails.
- Security token
If the user does not specify the user name and password with a job, the credential of the user is automatically persisted as a security token in the job database. The token contains the user security attributes, including groups. When a job is fetched, the token is used to authenticate and authorize against the administrative subsystem or the deployment manager.
For the same user registry configuration, John can submit a job against the first base node without specifying user name and password. The job runs because John's credential is automatically propagated as a security token to the administrative subsystem, and used to authenticate and authorize him for the job. If John submits a job against the second base node or the deployment manager cell, the job fails because his security token is not authorized in these two environments.
For the different user registry configuration, a user's security token does not automatically allow the submitted job to run against the administrative subsystem or the deployment manager. To enable a user token for a different realm, use the multiple security domain feature. First, we establish the job manager realm as a trusted realm for the registered base nodes and the deployment manager cell. In addition, import the access ID of the user from the job manager into the local authorization table and give the access ID a role. Then, the user can submit a job without passing user name and password.
Suppose John is an operator on the job manager, but his access ID is imported as an administrator in administrative authorization table of the first base node. Although John does not exist in the user registry of the base node, by passing the security token and the administrative authorization table definition, John is authorized as an administrator on the base node. John can submit a job for the first base node without having to specify a user name or password.
If John submits a job against the deployment manager, the job fails. John's security token is from the job manager realm, and John's access ID has not been authorized for the deployment manager. In this case, the administrator can export John's access ID from the job manager and import it to the deployment manager. Or, John can submit a job passing user name and password that he had with the deployment manager, which enables John to run jobs with monitor role.
The same mechanism works if the fine grained security feature is in use. We must be authorized in the authorization table for a new authorization group. The authorization table might also contain an external access ID.
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:
- We can always specify a user name and password during job submission if the target node or deployment manager recognizes your user name and password.
- If the job manager and the target node or deployment manager have the same user registry, then job submission does not require a user name and password. However, we must be authorized for the target node or deployment manager.
- If the job manager and the target node or deployment manager have different user registries, trusted realms have been established, and the access ID of the job submitter has been imported into the administrative authorization table of the target node or deployment manager, then job submission does not require a user name and password.
Related: