In a flexible management environment, a user ID must have the required authorization to use the job manager and to work with registered nodes.
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 that are managed by an administrative agent are registered to a job manager, you need the following roles to use the administrative agent and manage its nodes:
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.
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 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.
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:
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.
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, you must use the multiple security domain feature. First, you must establish the job manager realm as a trusted realm for the registered base nodes and the deployment manager cell. In addition, you must 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. You must be authorized in the authorization table for a new authorization group. The authorization table might also contain an external access ID.
In a more complex topology, where some cells share the same user registry and some cell do not, the following rules apply: