(zos)System Authorization Facility considerations for the operating system and application levels
There are a few things to consider when enabling System Authorization Facility (SAF) authorization for the operating system and application levels.
With WebSphere Application Server for z/OS , authorization can happen at two different levels:
- Resources can be protected at the operating system level. If a program accesses a protected resource, the resource manager uses a call to SAF to let the security manager, typically RACF , perform an authorization check.
- Resources can be protected at the application level. If a Java EE application has a security constraint, the container will use a SAF call to let the security manager (RACF) perform an authorization check.
When SAF authorization is enabled, authorization on any level is always performed by the operating system's security manager (RACF or an equivalent product). Therefore, it is essential that users are authenticated with a security manager (RACF) user ID. Refer to Summary of controls for more information.
When SAF Authorization is selected during systems customization, administrative EJBROLE profiles for all administrative roles are defined by the RACF jobs generated using the z/OS Profile Management Tool or the zpmt command. SAF authorization (the use of SAF EJBROLE profiles to assign SAF users and groups to roles) can be used as an authorization mechanism for all user registries. If SAF authorization is selected on the console it overrides any other authorization choice (such as Tivoli Access Manager authorization).
If we do not select local operating system, you must map the distributed identity to a SAF user id using one of two options. We can configure and install a JAAS login module to perform the mapping, or in WAS v8.0 we can use the SAF distributed identity mapping feature.
Note that SAF authorization is also supported for non-local operating system registries. If we turn on SAF, it becomes the default provider (will handle naming and administration functions). Enable SAF and it becomes the native authorization provider.
For more information, refer to Select a registry or repository.
When SAF Authorization is enabled, use SAF EJBROLE profiles to enforce Java EE roles (the profile name is the role name for the application). Additionally, we can define a SAF profile prefix, which is an eight or less character string that is prepended to every SAF EJBROLE profile name. Refer to the following articles for more information:
- System Authorization Facility for role-based authorization
- Special considerations for controlling access to naming roles using SAF authorization
- Role-based authorization
Note that when SAF Authorization is enabled, the Everyone and All Authenticated settings are ignored. These attributes are managed in RACF. Everyone and All Authenticated are intended for WebSphere Authorization when they are enabled.
- Everyone
- When SAF authorization is enabled, SAF uses user authentication to enforce access to web applications. If we select the Everyone setting, any user defined in the registry can sign onto the Web application, and subjects or principals are authenticated.
WebSphere Application Server for z/OS uses the default (unauthenticated) user ID, and an ACEE that checks for ACCESS( READ) access defined with the RESTRICTED attribute. Therefore, the universal access authority (UACC) does not apply. If, when SAF does not enforce authentication for ejbroles, we want everyone to be able to access a particular role, you must grant the default (unauthenticated) user ID ACCESS( READ) access to enables a request to run unauthenticated, If we do not grant the default user ID ACCESS( READ) access, RACF returns false to an unauthenticated request. .
- All Authenticated
- We can permit any name in the user registry to sign on to the web application (All user names are authenticated when signing on). We must define UACC(READ) on the profile being accessed and do not issue the RACF PERMIT command for the default user ID.
The universal access authority does not apply to users defined with the RESTRICTED attribute. For example, if we want the WebSphere unauthenticated identity to have READ access to an EJBROLE, then you must explicitly grant the id READ permission, regardless of the UACC setting.
When using a Local OS Registry, we can control access to console users .
If we decide at a future date to turn on SAF authorization, issue these RACF commands to enable proper WebSphere Application Server operation. (Change the value of the configured default user ID if we have chosen a different unauthenticated user ID.)
Related concepts
WAS security for z/OS Custom System Authorization Facility mapping modules
Related tasks
Writing a custom System Authorization Facility (SAF) mapping module with non-local operating system Configure a custom System Authorization Facility mapping module for WebSphere Application Server Enable pluggable login modules to map Java EE identities to System Authorization Facility (SAF) Controlling access to console users when using a Local OS Registry Use distributed identity mapping for SAF