Available runtime modes

Overview

BSA CI supports the following runtime modes for ports:

  • NOSSL
  • SSL
  • SSLAUTH

You can assign a different runtime mode to each port. The runtime mode of a port is specified as a positional parameter of the LST parameter Bnn_TCPIP_SSL_PORT[_app] in the LST member of the BSA CI.

NOSSL

  • NOSSL disables SSL in the BSA CI for this port.
  • The user logon is carried out via user ID/password.
  • No SSL handshake or certificates are exchanged.
  • Encryption and compression can be activated.
  • If the product application is a client, for example, a Beta 92 Open Systems (OSY) agent, communication is established without using SSL and/or certificates.
  • Authentication is not checked before establishing communication. Certificates are neither requested nor checked. Client authorization is checked via user ID/password within the z/OS security system. All subsequent communication will be processed in accordance with the compression and/or encryption selected.

Note: The runtime mode of the service port is always SSL, even if you use NOSSL for the application port. For more information, see "Defining a service port".

SSL

  • This is SSL without client certificates.
  • The server always sends its certificate to the client for the client to check (BSA CI always acts as the server during an SSL handshake).
  • The user logon is carried out via user ID/password.
  • When the product application is a client, e.g. a Beta 92 Open Systems (OSY) agent, certificate verification is sufficient to establish a communication.
  • For communication to take place, only a server certificate must be made available. Client certificates, if available, are neither requested nor checked.
  • When communication has been successfully established, all further communication is SSL-encrypted and the client authorization is carried out via user ID/password check within the z/OS security system.
  • Runtime mode SSL is defined for the application port and the service port.
  • The client must support SSL, and SSL support must be set as the runtime mode on the client side.

SSLAUTH

  • This is SSL with server authentication and client authentication.
  • The server and the client mutually exchange and check certificates.
  • The user logon is carried out via a client certificate and no longer via user ID/password.
  • When the product application is a client, e.g. a Beta 92 Open Systems (OSY) agent, the exchange of certificates is sufficient to establish a communication.
  • Valid client and server certificates are required and must be made available before communication can take place. Communication is only established if the client authentication is valid. For client authorization (logon to the z/OS security system, e.g. RACF), the client certificate is used. HostIdMapping can also be used to map a client certificate to a z/OS user ID. If the client certificate is invalid or if it cannot be mapped to a valid z/OS user ID, communication cannot be successfully established.
  • When authorization and authentication of the connection is successful, all further requests are processed SSL-secured.
  • The client must support SSL, and SSL support must be set as the runtime mode on the client side.

Note: The runtime mode of the service port is always SSL, even if you use SSLAUTH for the application port. For more information, see "Defining a service port".

Encryption and compression

  • If you are using application ports with runtime mode NOSSL, you can specify the application suffix in the compression and encryption parameters, for example, Bnn_TCPIP_COMPRESS_app (see "LST parameters for BSA CI").
  • Encryption and compression cannot be used for runtime modes SSLAUTH and SSL, and will be ignored.