Secure Sockets Layer security for WebSphere Application Server for 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 Lightweight Directory Access Protocol (LDAP) client.

The following information assumes you understand the Secure Sockets Layer (SSL) protocol and how Cryptographic Services System SSL works on z/OS®. For more information about the SSL protocol, see Introduction to SSL on the Oracle website.

SSL support is optional. However, when administrative security is enabled, SSL is always used by the administrative subsystem to secure administrative commands, the administration console, and communications between WebSphere Application Server processes. The SSL repertoire type is Java™ Secure Socket Extension (JSSE) .

The WebSphere Application Server for z/OS runtime can optionally use SSL when server security is enabled in the following cases:

To protect web applications 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, you can use SSL to perform client authentication when the CLIENT_CERT security constraint is specified during application deployment.
To protect Inter-ORB Protocol (IIOP) requests when SSL/TLS is supported or required in the Common Secure Interoperability version 2 (CSIv2) transport settings. You can enable these settings in the administrative console by clicking Security > Global security. Then, under RMI/IIOP security, click CSIv2 inbound transport or CSIv2 outbound transport.
To protect communications between an LDAP client and server when the active user registry is an LDAP registry.
To be securely interoperable with other products, such as Customer Information Control System (CICS®) Transaction Server for z/OS, other WebSphere Application Server versions, and Common Object Request Broker Architecture (CORBA)-compliant object request brokers.
To provide a secure communications medium through which various authentication protocols can operate.

The following constraints apply to SSL connections on WebSphere Application Server for z/OS.

JSSE is used as the SSL repertoire type for administrative requests that use the HTTP/SOAP Connector. The System SSL repertoire type is only used by the Daemon Address Space, because the daemon runs without a JVM and JSSE is only supported in Java.
JSSE repertoires can specify either a SAF keyring for the keystore or truststore, or an hierarchical file system (HFS) file. For System SSL type repertoires, you 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. For information about creating a key ring for the daemon's MVS user ID, see Setting up a keyring for use by Daemon Secure Sockets Layer.
Either a Java or C++ client on z/OS is interoperable with a WebSphere Application Server for z/OS or workstation Application Server, and can use SSL. However, CSIv2 security supports only Java clients on z/OS.
Part of the SSL handshake is to negotiate the cryptographic specs that are used for message protection. Two factors determine the cipher specs and key sizes that are used:
- The security level of the cryptographic services installed on the system, which determines the cipher specs and key sizes available to WebSphere Application Server for z/OS.
- The configuration of the server through the administrative console, which allows you to specify SSL cipher suites.

SSL and authentication on WebSphere Application Server for z/OS

SSL provides 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.

Server authentication

SSL support always provides a mechanism by which the server proves its identity.

For the client to authenticate the server, the server must possess a signed certificate that was 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, the client does not pass a client certificate 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.

For clients, you must 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, you must use the Resource Access Control Facility (RACF®) to create a client key ring and to attach the CA certificate to that key ring.

Client authentication

The SSL support on WebSphere Application Server for z/OS allows the following options for the client to prove its identity.

Basic authentication: With basic authentication, a client proves its identity to the server by passing a user identity and password or password phrase that is known by the target server. Because a password is always required on a basic authentication request, only simple client-to-server connections can be made. The server cannot send a client's user ID to another server for a response to a request.; A z/OS client can communicate securely with WebSphere Application Server for z/OS with a user ID and password as defined by the CSIv2 Generic Security Services Username Password (GSSUP) username and password mechanism. A WebSphere Application Server client can communicate securely with a WebSphere Application Server for z/OS server by using an MVS user ID and password or password phrase.; To define SSL basic authentication security, you must first request a signed certificate for your server and a certificate authority (CA) certificate from the certificate authority that signed your server certificate. After you receive a signed certificate for your server and a CA certificate from the certificate authority, you must use RACF to authorize the use of digital certificates and store server certificates and key rings. You must also create an SSL repertoire alias and define SSL security properties for your server through the administrative console.
Client certificate support: With client certificate support, both the server and client supply digital certificates to prove their identities to each other.; When digital certificates are provided for authentication to WebSphere Application Server 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 and managing client authentication can be an administrative burden. When the local operating system is the enabled user repository on WebSphere Application Server for z/OS, SAF certificate name filtering allows you to map client certificates to MVS user IDs without storing them. Through certificate name filtering, you can authorize sets of users to access servers without the administrative burden of creating MVS user IDs and managing client certificates for every user.
CSIv2 identity assertion: CSIv2 identity assertion supports z/OS principals, X501 distinguished names, and X509 digital certificates.
Identity assertion: Identity assertion, or trusted association, enables an intermediate server to send the identities of its clients to a target server securely and efficiently. This support uses client certificates to establish the intermediate server as the owner of an SSL session. Through 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. These client identities are simply asserted without requiring authentication.