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.Steps for this task
The server user ID does not run WebSphere Application Server processes. Rather, the process ID runs the WebSphere Application Server processes. The process ID is determined by the way the process starts. For example, if you use a command line to start processes, the user ID that is logged into the system is the process ID. If you choose the LocalOS registry, the process ID requires special privileges to call the operating system APIs. Specifically, the process ID must have the Act as Part of Operating System privileges on Windows systems or root privileges on a UNIX system.
Choose either the Common Secure Interoperability Version 2 (CSIv2) or Security Authentication Service (SAS) protocol.
The CSIv2 protocol is new to WebSphere Application Server Version 5 and has new features.
The SAS protocol still provides backward compatibility to previous product releases, but is being deprecated.
For details on configuring CSIv2 or SAS protocols, refer to the Configuring Common Secure Interoperability Version 2 and Security Authentication Service authentication protocols article.
These files protect the integrity of the messages being sent across the Internet. A single location is provided where you can specify SSL configurations that can be used among the various WebSphere Application Server features that use SSL, including the LDAP user registry, Web Container, and the Authentication Protocol (CSIv2 and SAS). To create a new keystore and truststore, see the Creating a keystore file and Creating truststore files articles. You can create different keystore and truststore files for different uses or create one set for everything that involves the server use of Secure Sockets Layer (SSL). Once you create these new keystore and truststore files, specify them in the SSL Configuration Repertoires. To get to the SSL Configuration Repertoires, click Security > SSL. You can either edit the "DefaultSSLConfig" or create a new SSL configuration with a new alias.
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).