Previous Topic: Client Security ProcessingNext Topic: Layer 1: Transaction Security


Server Security Processing

Regardless of how the client-side security data is provided and later associated with a cooperative flow, security data serves two primary objectives, as follows:

In other execution environments accessing the USER_ID is not allowed by the environment and would therefore use the USER_ID system attribute unavailable (EJBs and .NET Servers). More specifically, accessing the USER ID is not feasible; therefore, the TIRUSRID user exit does not exist in these server execution environments.

In those environments where the user ID context is accessible, the TIRUSRID user exit is invoked to obtain the user ID from the execution environment. This user exit is called soon after the Server Manager begins executing and before control is passed to the target DPS. The value of the USER_ID system attribute is populated as a result of executing TIRUSRID user exit.

Granting the execution access is security processing that can occur in more than one location along the execution path to a DPS. There can be up to as many as five layers of security processing that is incorporated when executing a DPS. These layers include the following security:

Each layer refines the granularity of what is being protected. The user that is associated with a cooperative request must be granted access at each layer that is implemented for processing to proceed. Depending on the execution environment, not all layers of security within a DPS is implemented.