This topic applies only on the z/OS operating system.

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:

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 Configuration Dialog. 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).

Note that if you do not select Local OS, you must configure and install a Java Authentication and Authorization Service (JAAS) login module to perform principal mapping that maps LDAP or custom registry principal to a SAF user ID.

Note that SAF authorization is also supported for non-Local OS 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 user registry.

When SAF Authorization is enabled, use SAF EJBROLE profiles to enforce J2EE roles (the profile name is the role name for the application). 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
Because no authentication is required (any user can sign on to the Web application and subjects or principals are not authenticated) for Everyone, RACF will return false if you do not take the following into consideration. WebSphere Application Server for z/OS uses the default (unauthenticated) user ID and uses an ACEE that checks for ACCESS( READ) access defined with the RESTRICTED attribute (the universal access authority (UACC) does not apply). If you want Everyone to be able to access a particular role, you must grant the default user ID READ access.
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.

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.)




Related concepts
Custom System Authorization Facility mapping modules
WebSphere Application Server security for z/OS
Related tasks
Writing a custom System Authorization Facility (SAF) mapping module with non-local operating system
Installing and configuring a custom System Authorization Facility mapping module for WebSphere Application Server
Enabling pluggable login modules to map J2EE identities to System Authorization Facility (SAF)
Controlling access to console users when using a Local OS Registry
Concept topic    

Terms of Use | Feedback

Last updated: Sep 20, 2010 10:03:57 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-zos&topic=csecsafauthz
File name: csec_safauthz.html