(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, WebSphere Application Server 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 WebSphere Application Server 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
- (zos) 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, WebSphere Application Server 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.
- (zos) Cluster authorizations
This section discusses the kinds of authorization checking WebSphere Application Server 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 concepts
Administrative security
Server process authorization checking