+

Search Tips   |   Advanced Search

Job scheduler security overview

The actions that a user can take against a job depend on the security model that is being enforced. User actions against a job can be role based, group based, or a combination of the two.


Role based security

When role-based security is enabled, you must be granted the lrsubmitter role, the lradmin role, or the lrmonitor role to act on a job. Users assigned the lradmin role have authority to perform all job scheduler application actions on all jobs regardless of job ownership. Users assigned the lrsubmitter role can view and act only on jobs that the submitter owns. Users assigned the lrmonitor role only can view jobs and job logs of all users.


Group security

In the group security model, group-affiliation alone is the basis for all job-related security decisions. The administrator does not assign job roles to specific users. A user can complete an action for a job only if the user and job are members of the same group. For example, if two users are members of the same group and each submits a job assigned to that same group, then both users can view and take actions against either of the two jobs.

Because WebSphere Application Server does role-based checking on job scheduler operations, you must make a single assignment of the lradmin role to All Authenticated in Application's Realm. Users in the group have the same privileges as the lradmin role and can perform the same operations against a job in the group that the lradmin role can perform.


User and group membership

The group security function requires either an implementation of the group membership SPI or a user repository that supports group membership, such as LDAP, and is configured as a federated repository.

Use the group membership filter SPI to augment the federated repository.

If we use a repository, configure the repository as a federated repository even if the WAS configuration is using only a single repository. The federated repositories function supports multiple repository technologies, including Local OS, LDAP, and Active Directory.

(zos) Additionally, the federated repositories function supports System Authorization Facility (SAF).

When you use a repository, define all WebSphere Application Server users and groups through the management facilities of the configured repository technology.


Group and role security

In the group and role security model, both group-affiliation and role-based security governs job-related security decisions. This means a user can take a job-related action only if the user and job are members of the same group, and the user's role permits the job action.

For example, if two users are members of the same group and each submits a job assigned to that same group, then both users can view and take actions against either of the two jobs, subject to their role assignments. If the first user is in the lradmin role, that user can view and take job actions against both jobs. If the second user is in the lrsubmitter role, that user can view and take job actions only against the job that the second user submitted. If the second user is in the lrmonitor role instead of the lrsubmitter role, that user is disallowed from submitting a job, but is permitted to view jobs submitted by the first user.


Related tasks

  • Secure the job scheduler using roles

    Secure the job scheduler using groups on distributed operating systems