Client application model

As shown in Figure 1, this type of application runs entirely within the security environment of a single user. Many users might use the application, but each usage is independent, runs in a separate process, and should not share System SSL information with other processes. All socket calls for each usage of the application are made from the same z/OS® UNIX process. Most connections are active connections initiated with the connect() service by this application to a server. Some client applications, such as web browsers, repeatedly connect to servers at the same or different IP addresses.

Some client applications, such as FTP or REXEC, support a second parallel connection with the server. This is often a passive connection, established by binding to an ephemeral port and listening for a single connection back from the server's IP address. For a description of an alternative method of mapping policy for these special cases, see Secondary connection application model.

Figure 1. Client application model
In security environment of 1 user, 2 client appls from same shell process initiate connections to server appl

All connections established by this application, whether active or passive, perform TLS handshake processing as a client. All of the connections established by a single process under the same user ID should be able to share the session ID cache in the SSL environment. If the server does not require client authentication, this client can use a shared key ring containing only the root certificates needed to validate the server's certificate. If the server does require client authentication, each user ID needs to own a key ring that contains that user's certificate, in addition to the necessary root certificates. RACF® key ring names are qualified with the owning user IDand are specified as userid/keyring. If the user ID is not explicitly specified on the AT-TLS key ring parameter, the current user ID is used. Therefore, key ring names can be the same across different user IDs . If the same key ring name is used by all client user IDs, a single TTLSEnvironmentAction keyring parameter can represent all clients required to support client authentication. AT-TLS policy administration is simplified if the individual key rings all have the same key ring name.