Setting up threads and security

z/OS UNIX supports two fundamental types of application servers: multithreaded servers and single-threaded servers.

A multithreaded server has multiple sequential flows of control. In this family of applications, the server can process more than one unit of work at a time.
A single-threaded server has one sequential flow of control. In this family of applications, the server processes one unit of work at a time.

z/OS UNIX provides the pthread_security_np() callable service and support through the C runtime library. It enables unauthorized multithreaded servers to create and delete a RACF® security environment in a way that is mediated and controlled by the kernel and RACF. Multithreaded servers can customize the security environment of a thread, thus allowing it to be executed under a different RACF identity than that of the server. You must authorize the server to use that service.

The term unauthorized refers to applications that are not APF-authorized and do not run in supervisor state or in a system storage protection key.

A server that uses the pthread_security_np() service can customize the RACF identity of a thread. This server initiates a thread that processes the client's request. If the server customizes the thread that is initiated for the client with the client's RACF identity, any resource access decisions to RACF-protected resources are made using the client's RACF identity and authorizations.

Depending on the trust you place in a server, you have the option of enforcing whether to use both the server's RACF identity and the RACF identity of the client in resource access control decisions on z/OS.

You can choose one of the following:

Only the RACF user ID of the client is used in local resource access control decisions that are made by RACF on z/OS.
Both the RACF user ID of the server and the RACF user ID of the client are used in local resource access control decisions on z/OS.

The use of the pthread_security_np() service is in part protected by the RACF FACILITY class profile BPX.SERVER. If this profile is defined, then the RACF user ID that is associated with the server needs at least READ authority to use the pthread_security_np() service.

If the RACF user ID that is associated with a server is permitted with UPDATE access to this profile, the server is allowed to establish a thread-level (task-level) security environment for clients connecting to the server. With UPDATE authority to BPX.SERVER in the RACF FACILITY class, the server can act as a surrogate of the client. This means that the identity of the thread associated with the request from the server's client executes with the z/OS user ID of the server's client.
The RACF identity of the client determines the type of access that is allowed to z/OS resources (such as data sets) and z/OS UNIX resources (such as UNIX files), which are accessed by the client's thread in the server.
READ access allows the server to establish a thread-level security environment for the clients it services. However, the user ID of the server and the user ID of the client must be authorized to the resources the server accesses. A thread-level security environment in which both the client's and server's identities are used in the access control decision, but a password or password phrase was not supplied by the client, is called an unauthenticated client security environment.
Depending on the design and implementation of the client/server application, a client might need to supply an authenticator to the server.

For example, the client might be prompted to supply a password, password phrase, or a password substitute, such as a RACF PassTicket, to the server to prove its identity. If a RACF password, password phrase, or PassTicket is specified as an option on the pthread_security_np() service, and it is valid for the client user ID, only the RACF user ID of the client is used in rendering access control decisions. This task level security environment created by a server is called an authenticated client security environment. Because the client has trusted the server sufficiently to supply a RACF password, password phrase, or PassTicket to the server, the server can act as a surrogate for that client.

This capability enables you to determine on behalf of which user IDs the server can act and what resources the server can access when acting on behalf of one of its clients.

Potentially, for additional security checking, two audit records can be produced to audit the client accessing the resource and the server accessing the resource on behalf of the client.

If you choose to implement this additional security checking, you might need to authorize the identity that is associated with the server to the resource profiles that protect the resources accessed by the server on behalf of its clients.