This topic assumes you understand the Secure Sockets Layer
(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 Lightweight Directory Access Protocol (LDAP) client.
Configuring SSL is different between client and server with WebSphere Application Server. If you want
the added security of protected communications and user authentication
in a network, you can use SSL security.
SSL is an integral part of the security provided by WebSphere Application
Server 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 WebSphere Application Server processes.
The WebSphere Application Server 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, you 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 WebSphere Application Server for z/OS.
The type of repertoire relates to the underlying services used to
process SSL.
- Java Secure Socket Extension (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.
Note: All SSL configuration repertoires of the System Secure
Sockets Layer (SSSL) type, except those that belong to the daemon,
are converted to the Java Secure Socket Extension (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
Secure Sockets Layer (SSL) is used by multiple components within WebSphere Application Server 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 WebSphere Application
Server. If you want the added security of protected communications
and user authentication in a network, you can use Secure Sockets Layer
(SSL) security. The SSL support in WebSphere Application
Server 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 WebSphere Application Server 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 WebSphere Application Server 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 WebSphere Application Server client can
communicate securely with a WebSphere Application Server
for z/OS server by 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 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, which makes managing client authentication
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, without storing them, to MVS user
IDs. Through certificate name filtering, you 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 WebSphere Application Server versions
- Common Object Request Broker Architecture (CORBA)-compliant object
request brokers
SSL is disabled by default and SSL support is optional. If you
are running WebSphere Application Server for z/OS with
security turned on, SSL is required by the administrative console. Java Secure Socket Extension (JSSE) is the SSL
repertoire type used.
Table 1. SSL connection sequence. This
table describes how an SSL connection works.
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 WebSphere Application Server
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 WebSphere Application Server for z/OS.
- The configuration of the server through the administrative console
allows you to specify SSL cipher suites.
For more information, see z/OS System
Secure Sockets Layer Programming.
- For z/OS system SSL sockets 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.
Tip: 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 have received 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, store server certificates, and server key rings in RACF,
create an SSL repertoire alias, and define SSL security properties
for your server through the administrative console.
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 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 Setting up a keyring for use by Daemon Secure Sockets Layer for information
on creating a keyring for the daemon's MVS user
ID.