Accessing z/OS security resources using WZSSAD
The WLP z/OS® System Security Access Domain (WZSSAD) refers to the permissions granted to the Liberty server. These permissions control which System Authorization Facility (SAF) application domains and resource profiles the server is permitted to query when authenticating and authorizing users.
For example, if you want to set up two Liberty server instances, one for production and one for test and you want your role access to be different between production and test, you can set up two different System Security Access Domains.
The Liberty server is an unauthorized program that can be configured and run by non-administrator or non-privileged users, so it is important for system security and integrity purposes that the user is prevented from leveraging the server to run security operations for which they have not been explicitly granted permission.
- Authenticating a user
- Authorizing a Subject to a Java™ EE role
- Authorizing a Subject to other SAF resources
Authenticating a user
The server authenticates users to a particular SAF domain that is configured by defining a resource, which is referred to as the APPLID in the APPL class. In order to authenticate a user to the domain, the user must have READ access to the APPLID resource in the APPL class. In addition, whenever the APPL class is active, the unauthenticated user ID (which is WSGUEST by default) also requires READ access to the APPLID resource in the APPL class.
The APPLID resource name used by the server is specified by the
profilePrefix attribute in the <safCredentials>
configuration element. If you do not specify this element, then the default profilePrefix of
BBGZDFLT is used.
<safCredentials profilePrefix="BBGZDFLT"/>
// Define the BBGZDFLT APPLID to RACF.
RDEFINE APPL BBGZDFLT UACC(NONE)
// Activate the APPL class.
//If not active, the domain is not restricted, which means anyone can authenticate to it.
SETROPTS CLASSACT(APPL)
//All users to be authenticated by the server must have READ access to the APPLID in the APPL class:
PERMIT BBGZDFLT CLASS(APPL) ACCESS(READ) ID(UserID)
//The unauthenticated user ID requires READ access to the APPLID in the APPL class:
PERMIT BBGZDFLT CLASS(APPL) ACCESS(READ) ID(WSGUEST)
RDEFINE SERVER BBG.SECPFX.BBGZDFLT UACC(NONE)
PERMIT BBG.SECPFX.BBGZDFLT CLASS(SERVER) ACCESS(READ) ID(serverUserId)
Authorizing a Subject to a Java EE role
{profilePrefix}.{resource}.{role}
. For
example:profilePrefix="BBGZDFLT"
Application resource name = "MYAPP"
Application role name = "ADMIN"
Mapped profile name = "BBGZDFLT.MYAPP.ADMIN"
For more information, see Controlling how roles are mapped to SAF Profiles
EJBROLE profile name = "BBGZDFLT.ADMIN"
HLQ = "BBGZDFLT"
RDEFINE SERVER BBG.SECPFX.BBGZDFLT UACC(NONE)
PERMIT BBG.SECPFX.BBGZDFLT CLASS(SERVER) ACCESS(READ) ID(serverUserId)
In the example,
because the SAF role mapper sets the HLQ of the mapped profile to the profilePrefix, the same
profile BBG.SECPFX.BBGZDFLT governs both the APPLID authentication permissions, and the EJBROLE
profile authorization permissions.Authorizing a Subject to other SAF resources
Java EE applications can perform access control checks against SAF classes other than EJBROLE. The WZSSAD restricts which SAF classes outside of EJBROLE the server is allowed to authorize against. This prevents an unauthorized user or application from leveraging the server's use of authorized SAF services to discover information about which resource profiles in non-EJBROLE SAF classes the user or application is or is not authorized to.
RDEFINE SERVER BBG.SECCLASS.FACILITY UACC(NONE)
PERMIT BBG.SECCLASS.FACILITY CLASS(SERVER) ACCESS(READ) ID(serverUserId)