WebSphere Application Server Version 6.1 Feature Pack for Web Services
             Operating Systems: z/OS

             Personalize the table of contents and search results
This topic applies only on the z/OS operating system.

Secure Sockets Layer security for WebSphere Application Server for z/OS

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:
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.

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:
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

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.




Subtopics
SSL repertoires
Daemon Secure Sockets Layer
Related concepts
WebSphere Application Server security for z/OS
Concept topic    

Terms of Use | Feedback

Last updated: Nov 25, 2008 2:35:59 AM CST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/csec_settingupssl.html