(ZOS) Secure Sockets Layer security for WAS for z/OS

This topic assumes we understand the SSL protocol and how cryptographic services system SSL works on z/OS . SSL is used by multiple components within WebSphere Application Server to provide trust and privacy. Such components include the built-in HTTP transport, the Object Request Broker (ORB) (client and server), and the secure LDAP client. Configuring SSL is different between client and server with WAS. If we want the added security of protected communications and user authentication in a network, we can use SSL security.

SSL is an integral part of the security provided by WAS for z/OS. It is activated when administrative security is enabled. When administrative security is enabled, SSL is always used by the administrative subsystem to secure administrative commands, the administration console, and communications between WAS processes.

The WAS for z/OS runtime can optionally use SSL when server security is enabled in these cases:

• SSL is used to protect web application when confidentiality is specified as a Web Application Security Constraint. A transport guarantee of CONFIDENTIAL or INTEGRAL guarantees that the communication between the web client and the web server is secured and is transported over HTTPS (HTTP SSL). In addition, we can use SSL to perform client authentication when the security constraint (CLIENT_CERT) is specified during application deployment .
• SSL can be used to protect Inter-ORB Protocol (IIOP) requests when SSL/TLS is supported (or required) in the Common Secure Interoperability version 2 (CSIv2) transport settings. These are set by clicking Security > Global security. Under RMI/IIOP security, click CSIv2 inbound transport or CSIv2 outbound transport.
• SSL can be used to protect communications between an LDAP client and server when the active user registry is LDAP.

When configuring SSL, there are two types of SSL repertoires on WAS for z/OS. The type of repertoire relates to the underlying services used to process SSL.

• JSSE must be selected as the SSL repertoire type for administrative requests using the HTTP/SOAP Connector. JSSE repertoires can (with APAR PQ77586 applied) specify either a SAF keyring for the keystore or truststore, or an hierarchical file system (HFS) file.

All SSL configuration repertoires of the System Secure Sockets Layer (SSSL) type, except those that belong to the daemon, are converted to the JSSE type. System SSL is now only used by the Daemon Address Space because the daemon runs without a JVM and JSSE is only supported in Java.

This topic gives a brief explanation of the SSL protocol and how SSL works on z/OS. For information about the SSL protocol, go to the following website: http://home.netscape.com/eng/ssl3/ssl-toc.html

SSL is used by multiple components within WAS to provide trust and privacy. These components are the built-in HTTP Transport, the ORB (client and server), and the secure LDAP client. Configuring SSL is different between client and server with WAS. If we want the added security of protected communications and user authentication in a network, we can use SSL security. The SSL support in WAS for z/OS has several objectives:

• To provide ways accepted by the industry to protect the security of messages as they flow across the network. This is often called transport layer security. Transport Layer Security (TLS) is a function that provides privacy and data integrity between two communicating applications. The protection occurs in a layer of software on top of the base transport protocol (for example, on top of TCP/IP).

  SSL provides security over the communications link through encryption technology, ensuring the integrity of messages in a network. Because communications are encrypted between two parties, a third party cannot tamper with messages. SSL also provides confidentiality (ensuring the message content cannot be read), replay detection, and out-of-sequence detection.

• To provide a secure communications medium through which various authentication protocols can operate. A single SSL session can carry multiple authentication protocols, that is, methods to prove the identities of the parties communicating.

  SSL support always provides a mechanism by which the server proves its identity. The SSL support on WAS for z/OS allows these ways for the client to prove its identity:

  • Basic authentication (also known as SSL Type 1 authentication), in which a client proves its identity to the server by passing a user identity and password (or password phrase) known by the target server.

    With SSL basic authentication:

    • A z/OS client can communicate securely with WAS for z/OS with a user ID and password as defined by the CSIv2 user name and password mechanism Generic Security Services Username Password (GSSUP).
    • A WAS client can communicate securely with a WAS for z/OS server using a MVS™ user ID and password (or password phrase).
    • Because a password is always required on a request, only simple client-to-server connections can be made. That is, the server cannot send a client's user ID to another server for a response to a request.

  • Client certificate support, in which both the server and client supply digital certificates to prove their identities to each other.

    When digital certificates are provided for authentication to WAS for z/OS the decrypted certificate is mapped to a valid user identity in the enabled user repository. Web applications can have thousands of clients, which makes managing client authentication an administrative burden. When the local operating system is the enabled user repository on WAS for z/OS, SAF certificate name filtering allows you to map client certificates, without storing them, to MVS user IDs. Through certificate name filtering, we can authorize sets of users to access servers without the administrative overhead of creating MVS user IDs and managing client certificates for every user.

  • SSL support always provides a mechanism by which the server proves its identity. A variety of mechanisms can be used to prove the clients identity. The SSL v3 (and TLS) protocol provides for the ability for client digital certificates to optionally be exchanged. These certificates can be used for authentication.
  • CSIv2 identity assertion, which provides support for z/OS principals, X501 distinguished names, and X509 digital certificates.
  • Identity assertion, or trusted association, in which an intermediate server can send the identities of its clients to a target server in a secure yet efficient manner. This support uses client certificates to establish the intermediate server as the owner of an SSL session. Through the Resource Access Control Facility (RACF ), the system can check that the intermediate server can be trusted (to confer this level of trust, CBIND authorization is granted by administrators to RACF IDs that run secure system code exclusively). After trust in this intermediate server is established, client identities (MVS user IDs) need not be separately verified by the target server; those client identities are simply asserted without requiring authentication.

• To be securely interoperable with other products, such as:
  • Customer Information Control System (CICS ) Transaction Server for z/OS
  • Other WAS versions
  • Common Object Request Broker Architecture (CORBA)-compliant object request brokers

SSL is disabled by default and SSL support is optional. If we are running WAS for z/OS with security turned on, SSL is required by the administrative console. JSSE is the SSL repertoire type used.

Stage	Description
Negotiation	After the client locates the server, the client and server negotiate the type of security for communications. If SSL is to be used, the client is told to connect to a special SSL port.
Handshake	The client connects to the SSL port and the SSL handshake occurs. If successful, encrypted communication starts. The client authenticates the server by inspecting the server's digital certificate. If client certificates are used during the handshake, the server authenticates the client by inspecting the client's digital certificate.
Ongoing communication	During the SSL handshake, the client and server negotiate a cipher spec to be used to encrypt communications.
First client request	The determination of client identity depends upon the client authentication mechanism chosen, which is one of the following: CSIv2 user ID and password (GSSUP) CSIv2 asserted identity

Rules

• Either a Java or C++ client on z/OS is interoperable with a WAS for z/OS or workstation Application Server, and can use SSL. CSIv2 security only supports Java clients on z/OS.
• Part of the handshake is to negotiate the cryptographic specs used by SSL for message protection. There are two factors that determine the cipher specs and key sizes used:
  • The security level of the cryptographic services installed on the system, which determines the cipher specs and key sizes available to WAS for z/OS.
  • The configuration of the server through the administrative console allows us to specify SSL cipher suites.

  See z/OS System Secure Sockets Layer Programming.

• For z/OS system SSL sockets we must use RACF or an equivalent to store digital certificates and keys. Placing digital certificates and keys into a key database in the HFS is not an option.

Tip: To define SSL basic authentication security, first request a signed certificate for the server and a certificate authority (CA) certificate from the certificate authority that signed the server certificate. After we have received a signed certificate for the server and a CA certificate from the certificate authority, we must use RACF to authorize the use of digital certificates, store server certificates, and server key rings in RACF, create an SSL repertoire alias, and define SSL security properties for the server through the administrative console.

For clients, create a key ring and attach to it the CA certificate from the certificate authority that issued the server's certificate. For a z/OS client, we must use RACF to create a client key ring and to attach the CA certificate to that key ring. For the client to authenticate the server, the server (actually, the controller user ID) must possess a signed certificate created by a certificate authority. The server passes the signed certificate to prove its identity to the client. The client must possess the CA certificate from the same certificate authority that issued the server's certificate. The client uses the CA certificate to verify that the server's certificate is authentic. After the certificate is verified, the client can be sure that messages are truly coming from that server, not someone else. For the server to authenticate the client, note that there is no client certificate that the client passes to prove its identity to the server. In the SSL basic authentication scheme, the server authenticates the client by challenging the client for a user ID and password (or password phrase).

See Set up a keyring for use by Daemon Secure Sockets Layer for information on creating a keyring for the daemon's MVS user ID.

Subtopics

• SSL repertoires
  With SSL configuration repertoire, administrators can define any number of SSL settings that can be used to make HyperText Transport Protocol SSL (HTTPS), Internet Inter-ORB Protocol SSL (IIOPS) or LDAP SSL (LDAPS) connections.

• Daemon Secure Sockets Layer
  Use the administrative console panel to modify the port and SSL port settings and to specify the SSL settings (the SSL repertoire). The default repertoire is the same one used for the server, which is a SystemSSL IIOP repertoire. During daemon initialization the SSL usage initialization is attempted if security is enabled and a valid repertoire is found. In order to turn off the daemon SSL port a cell-level WebSphere variable (DAEMON_security_disable_daemon_ssl) must be created and set to 1. The default for this variable is 0.

Related:

WAS security for z/OS