Before you begin
It is helpful to understand security from an infrastructure standpoint so that you know the advantages of different authentication mechanisms, user registries, authentication protocols, and so on. Picking the right security components to meet your needs is a part of configuring global security. The following sections help you make these decisions. Read the following articles before continuing with the security configuration.
After you understand the security components, you can proceed to configure global security in WebSphere Application Server.Note: There are some security customization tasks required to enable security on WebSphere Application Server for z/OS that require updates to the security server (such as Resource Access Control Facility (RACF)) running on your system. You might need to include your security administrator in this process. Refer to Security customization dialog settings for details on customization procedures.
Steps for this task
Refer to Configuring single signon if you want single signon (SSO) support, which provides the ability for browsers to visit different product servers without having to authenticate multiple times. For form-based login, you must configure SSO when using LTPA or ICSF.
Choose either the Common Secure Interoperability Version 2 (CSIv2) or Security Authentication Service (zSAS) protocol.
The CSIv2 protocol is new to WebSphere Application Server Version 5 and has new features.
The z/SAS protocol still provides backward compatibility to previous product releases, but is being deprecated.
For details on configuring CSIv2 or z/SAS protocols, refer to the Configuring Common Secure Interoperability Version 2 and Security Authentication Service authentication protocols article.
Note: A RACF key ring is uniquely identified by both the key ring name in the repertoire and the MVS user ID of the server controller process. If different WebSphere Application Server controller processes have unique MVS user IDs, you must be sure that a RACF key ring and a private key are generated even if they share the same repertoire.
There are two kinds of configurable SSL repertoires:
Users must configure a System SSL repertoire to use HTTP or IIOP protocols and a JMX connector must be configured to use SSL. If the SOAP HTTP connector (default) is chosen, a JSSE repertoire must be selected for the administrative subsystem. In a Network Deployment environment, click System Administration > Deployment Manager > Administration Services > JMX Connectors > SOAP Connector > Custom Properties > sslConfig.
A set of SSL repertoires are set up by the z/OS installation dialogs. These dialogs are configured to refer to SAF key rings and to files that are populated by the customization process when generating RACF commands.
Repertoire name | Type | Default use |
---|---|---|
DefaultSSLSettings | JSSE | SOAP JMX connector, SOAP client |
DefaultHTTPS | SSSL | Web container HTTP transport |
DefaultIIOPSSL | SSSL | z/SAS and CSIV2 |
RACFJSSESettings | SSSL | None |
RACFJSSESettings | JSSE | None |
No additional action is required if these settings are sufficient for your needs. If your want to create or modify these settings, you must ensure that the keystores to which they refer are created.
For System SSL repertoires, the same key ring must be used in every System SSL repertoire used by the server.
If you do create a new alias for your new keystore and truststore files, change every location that references the SSL configuration alias DefaultSSLConfig. The following list provides these locations:
This panel performs a final validation of the security configuration. When you click OK or Apply from this panel, the security validation routine is performed and any problems are reported at the top of the page. When you complete all of the fields, click OK or Apply to accept the selected settings. Click Save (at the top of the panel) to persist these settings out to a file. If you see any informational messages in red text color, then a problem exists with the security validation. Typically, the message indicates the problem. So, review your configuration to verify that the user registry settings are accurate and that the correct registry is selected. In some cases, the LTPA configuration might not be fully specified. See the Global security and server security article for detailed information.
Enabling global security differs from a stand-alone base application server. In the Network Deployment environment, the configuration is stored temporarily in the deployment manager until it is synchronized with all of the node agents. To save the configuration, click Save in the menu bar at the top of the panel.
Verify that all of the node agents are up and running in the domain. It is recommended that you stop all application servers during this process. If any of the node agents are down, run a manual file synchronization utility from the node agent machine to synchronize the security configuration from the deployment manager. Otherwise, the malfunctioning node agent does not communicate with the deployment manager after security is enabled on the deployment manager.
Important: If security is enabled on a WebSphere Application Server 5.x environment and the deployment manager is upgraded to the next cumulative level (but the base node is not), synchronization fails because the default SSL Keys in ND and Base do not match. You should create your own trust stores and key stores for production systems (default ones are suggested only for testing purposes).