Server application model

As shown in Figure 1, this type of application runs entirely within a single z/OS® UNIX process. Connections can be either passive connections returned from a listening socket by the accept() service, or active connections initiated with the connect() service. Communication partners can be client applications or peer servers. Connections can be processed by subtasks or pthreads within the server process. The initial read or write of data on the connection is done under the primary security environment of the server process. Some server applications allow a client to log in with a user ID on the server system and can place this client-specified identity on the subtask or pthread used to access resources on behalf of the client. The user ID associated with the server is used for AT-TLS purposes, regardless of this ability to change to the client-specified identity.

Figure 1. Server application model
Single z/OS UNIX process, client appls connect to server appl with active connection or with passive connection

Connections established by this application, whether active or passive, can perform TLS handshake processing as either a client or server. All of the connections established by a single process, under the same user ID and performing the handshake as a client or as a server, should be able to share a session ID cache in the SSL environment. The server process should use a private key ring with a server certificate. The key ring used must contain the chain of root certificates needed to validate the server certificate it presents to the client. If the server requires client authentication, it must also have any other root certificates necessary to validate the client certificates presented on its key ring.