(ZOS) Authorization checking

Each controller, servant, and client must be associated with an MVS™ user ID. When a request flows from a client to the server or from a server to another server, WebSphere Application Server for z/OS passes the user identity (client or server) with the request. This way, each request is performed on behalf of the user identity and the system checks to see if the user identity has the authority to make such a request.

When security is enabled, WAS administrative and Java EE authorizations can be performed using the identity authenticated with the configured user registry or repository.

When the user registry or repository is configured to be the local operating system, the operating system and WAS identities are the same. We can configure authorization to use either WebSphere Authorization, System Authorization Facility (SAF) authorization, or a Java Authorization Contract for Containers (JACC) external provider.

Subtopics

• Summary of controls
  Each controller, servant, and client must have its own MVS user ID. When a request flows from a client to the cluster or from a cluster to a cluster, WAS for z/OS passes the user identity (client or cluster) with the request. Thus, each request is performed on behalf of the user identity and the system checks to see if the user identity has the authority to make such a request. The tables outline System Authorization Facility (SAF) and non-SAF authorizations.

• Cluster authorizations
  This section discusses the kinds of authorization checking WAS for z/OS does for a clusters. Servants must have access to profiles in the RACF SERVER class. This controls whether a servant can call authorized routines in the controller.

Related:

Administrative security

Server process authorization checking