This topic assumes you understand the Secure Sockets Layer (SSL)
protocol and how cryptographic services b 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
> Secure administration, applications, and infrastructure. Under RMI/IIOP
security, click CSIv2 inbound transport or CSIv2 outbound transport.
- SSL can be used to protect IIOP requests when z/OS Secure Authentication
Services (z/SAS) protocols are selected. SSL is used with SSL basic authentication,
SSL client authentication, z/SAS identity assertion, and z/SAS Kerberos. SSL
client authentication and z/SAS identity assertion also uses SSL transmitted
digital certificates to authenticate the sender of the request.
- 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.
- System SSL (SSSL repertoires) are required for Web container (HTTP Transports)
SSL, and Inter-ORB (IIOP) SSL processing, both CSIv2 and zSAS SSL Transports.
In addition, a System SSL repertoire must be specified if the Remote Method
Invocation (RMI) connector is chosen for administrative requests. System SSL
repertoires use a System Authorization Facility (SAF) keyring to retrieve
the personal certificate and trust stores of the Application Server.
- 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.
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 Web site: http://home.netscape.com/eng/ssl3/ssl-toc.html
For more information about Cryptographic Services System SSL, go to the
following Web site: z/OS System Secure Sockets Layer Programming.
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 (or password phrase) 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
The following 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
- zSAS Kerberos
- zSAS basic authentication assertediIdentities
- zSAS asserted identities
- CSIv2 client certificates
- zSAS client certificates
|
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.