InfoCenter Home >
5: Securing applications -- special topics >
5.9: Configuring security interoperation with WebSphereon z/OS

5.9: Configuring security interoperation with WebSphere on z/OS

WebSphere Application Server Advanced Edition supports interoperability between application servers running on UNIX or NT platforms and application servers running on the z/OS platform. This support allows application servers on the UNIX or NT side to authenticate to the application server on the z/OS side and communicate securely. Unauthenticated requests from the UNIX- or NT-based application servers are rejected. Authentication is supported between application servers, not individual applications.

To configure this support, serveral steps must be taken. WebSphere security must be enabled on both sides. Information used for authenticating to the z/OS-based application server must be collected and stored in a key file for use by the UNIX- or NT-based application server. The Secure Sockets Layer (SSL) protocol, which is used to secure the communication channel, requires that the UNIX- or NT-based server also have a valid certificate for the z/OS-based application server. Finally, the UNIX- or NT-based applications must be configured to use the appropriate identities so that they can communicate with the z/OS-based application servers. The following describes the specific steps that must be taken:

  1. Collect the login information for the z/OS-based application server and store it in a key file for use by the UNIX- or NT-based application server. See Creating the key file for more information.
  2. Enable global security for WebSphere Application Server for the UNIX- or NT-based application servers. See 6.6.18: Securing applications for more information.
  3. Enable global security for WebSphere Application Server for the z/OS-based application server. See WebSphere Application Server V4.0 for z/OS and OS/390: Installation and Customization for more information; this can be reached from the Library link on the main WebSphere Application Server page.
  4. Create a certificate for use by the UNIX- or NT-based application server, as required by the SSL protocol. See Creating the certificate for more information.
  5. Configure the UNIX- or NT-based applications to use the identity of the application server when communicating with z/OS-based applications. See Configuration for interoperation for more specific information or 6.6.18: Securing applications for general information.
  6. Configure the z/OS-based application server to accept communications from the UNIX- or NT-based application servers. See WebSphere Application Server V4.0 for z/OS and OS/390: Installation and Customization for more information; this can be reached from the Library link on the main WebSphere Application Server page.

Creating the key file

The UNIX- or NT-based application servers must have access to the information needed to authenticate to each z/OS-based application server. The login information, which includes the target realm, user ID, and password, for every z/OS target must be stored in a local text file. The passwords in this file are encoded when the security service processes the file, but it is also suggested that access to the file itself be restricted by storing the file in a securable file system and setting permissions appropriately. For example, on a Windows-based system, NTFS partitions systems are securable, but DOS partitions are not.

The information in the key file must be formatted as follows:

  • Each entry must contain these three pieces of information, in the order specified, separated by spaces:
    1. Realm name: The IP name of the Daemon Server in WebSphere for z/OS.
    2. User ID: The user ID defined for SSL-secured servers on the z/OS platform.
    3. Password: The password corresponding to the user ID defined for SSL-secured servers.
  • The file must contain no blank lines.
  • Use the hash (#) character to include comments and other informational lines.
  • All comments must begin on new lines; they cannot appear after the authentication entries on the same line.

A sample file is provided with WebSphere Application Server. This file, wsserver.key, is installed in the <product_installation_root>/properties directory. It can be copied or modified. The following also illustrates the structure of the file:

# Sample key file
#
# First target realm
#
TargetRealm serverID serverPassword
#
# Second target realm
#
TargetRealm2 serverID2 serverPassword2
#
# End of key file

Creating the certificate

The SSL protocol is used to protect communication between the UNIX- or NT-based application server and the z/OS-based application server. To complete the SSL handshake between them, the UNIX- or NT-based application server must hold a valid key certificate. To create this certificate, perform the following steps:

  1. On the z/OS side, extract the public key of the z/OS-based application server by using the z/OS key-management tools. See WebSphere Application Server V4.0 for z/OS and OS/390: Installation and Customization for more information; this can be reached from the Library link on the main WebSphere Application Server page.
  2. On the UNIX or NT side, open the certificate for the UNIX- or NT-based application server and add the public key of the z/OS-based application server as a signer certificate. See 5.5.6: Tools for managing certificates and keys for more information on the tools and techniques for managing certificates.

Configuration for interoperation

Before UNIX- or NT-based application servers and z/OS-based applications servers can interoperate, the application servers and applications must be configured for interoperation. On the UNIX or NT side, this involves the following:

  • Configuring application resources, for example, enterprise beans, that must access the z/OS-based application server to run under the identity of the hosting application server. In the interoperability scenario, it is the application servers, not individual applications, that authenticate, so resources like enterprise beans must run under the identity of application server. For example, before deploying an enterprise bean that can contact the z/OS-based application server, the RunAs identity of the bean must be set to System Identity.
  • Setting properties for the application server so that it can find the key file and key certificate containing the information about the z/OS-based application servers. The following properties must be set:
    • com.ibm.CORBA.loginSource: set to key file.
    • com.ibm.CORBA.keyFileName: set to the absolute path of the key file. For example, C:\WebSphere\AppServer\properties\wsserver.key.
    • com.ibm.CORBA.SSLClientKeyRing: set to the absolute path of the key certificate file containing the public key of the z/OS-based application server.
    • com.ibm.CORBA.SSLClientKeyRingPassword: set to the password protecting the file specified in the com.ibm.CORBA.SSLClientKeyRing property.
    • com.ibm.CORBA.requestTimeout and com.ibm.CORBA.locateRequestTimeout: set both properties to 0 in the sas.client.props and sas.server.props files. The reason for this is that, when a WebSphere application server on z/OS first starts, it has no regions available for processing work. Setting these timeout properties to zero prevents timeouts from occurring before the regions are established.

Go to previous article: Troubleshooting SSO configurations Go to next article: Administer applications

 

 
Go to previous article: Troubleshooting SSO configurations Go to next article: Administer applications