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™ Platform, Enterprise Edition (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. To ensure that SMF Type 83 records are able to be recorded successfully for those processes (like the servant process) that is not running in system key and supervisor state, You need to establish SAF authorization in the RACF profile for IRR.RAUDITX in the FACILITY class (FACILITY class(IRR.RAUDITX)). 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 administrative console it overrides any other authorization choice (such as Tivoli® Access Manager authorization).

If you do not select local operating system, you must map the distributed identity to a SAF user id using one of two options. You can configure and install a Java Authentication and Authorization Service (JAAS) login module to perform the mapping, or in WebSphere Application Server Version 8.0 you can use the SAF distributed identity mapping feature.

Note that SAF authorization is also supported for non-local operating system registries. If you 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 Selecting 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, you 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:

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 you 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, you 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 you do not grant the default user ID ACCESS( READ) access, RACF returns false to an unauthenticated request. .
All Authenticated: You can permit any name in the user registry to sign on to the web application (All user names are authenticated when signing on). You must define UACC(READ) on the profile being accessed and do not issue the RACF PERMIT command for the default user ID.
Note: The universal access authority does not apply to users defined with the RESTRICTED attribute. For example, if you 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, you can control access to console users .

If you decide at a future date to turn on SAF authorization, you must issue these RACF commands to enable proper WebSphere Application Server operation. (Change the value of the configured default user ID if you have chosen a different unauthenticated user ID.)