Configure global security

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

  1. Start the WebSphere Application Server administrative console by clicking http://yourhost.domain:9090/admin after starting the WAS.If security is currently disabled, log in with any user ID. If security is currently enabled, log in with a predefined administrative ID and password (this is typically the server user ID specified when you configured the user registry).

  2. Click Security from the left navigation menu. Configure the authentication mechanism, user registry, and so on.The configuration order is not important. However, when you select the Enabled flag in the Global Security panel, verify that all these tasks are completed. When you click Apply or OK and the Enabled flag is set, a verification occurs to see if the administrative user ID and password can be authenticated to the configured user registry. If you do not configured these, the validation fails.

  3. Configure a user registry. For more information, see Configuring user registries. Configure (LocalOS, LDAP, or Custom), and then specify details about that registry. One of the details common to all user registries is the server user ID. This ID is a member of the chosen user registry, but also has special privileges in WAS. The privileges for this ID and the privileges associated with the administrative role ID are the same. The server user ID can access all protected administrative methods. On Windows systems, the ID must not be the same name as the machine name of your system, since the registry sometimes returns machine-specific information when querying a user of the same name. In LDAP user registries, verify that the server user ID is a member of the registry and not just the LDAP administrative role ID. The entry must be searchable.

    The server user ID does not run WAS processes. Rather, the process ID runs the WAS processes.The process ID runs the WAS 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 running as a service, the user ID that is logged into the system is the user ID running the service. 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.

  4. Configure the authentication mechanism.To get details about configuring authentication mechanisms, read the Configuring Authentication Mechanisms article. There are two authentication mechanisms to choose from in the Global Security panel: Simple WebSphere Authentication Mechanism (SWAM) and Lightweight Third Party authentication (LTPA). However, only LTPA requires any additional configuration parameters. Use the SWAM option for single server requirements. Use the LTPA option for multi-server distributed requirements. SWAM credentials are not forwardable to other machines and for that reason do not expire. Credentials for LTPA are forwardable to other machines and for security reasons do expire. This expiration time is configurable. If you choose to go with LTPA, then Configuring single signon support. This support permits browsers to visit different product servers without having to authenticate multiple times.

  5. Configure the authentication protocol for special security requirements from Java clients, if needed. This task entails choosing a protocol, either CSIv2 or SAS. The CSIv2 protocol is new to WAS v5 and has many new and improved features. The SAS protocol is still provided as a backwards compatibility to previous product releases but is being deprecated. For details on configuring CSIv2 or SAS, see the article, Configuring CSIv2 and SAS authentication protocols.

  6. Modify the default SSL keystore and truststore files that are packaged with the product.This action protects the integrity of the messages sent across the Internet. WAS provides a single location where you can specify SSL configurations that the various WAS features that use SSL can utilize, including the LDAP user registry, Web container and the authentication protocol (CSIv2 and SAS). Create a new keystore and truststore, by referring to the Creating keystore files and Creating truststore files articles. You can create different keystore files and truststore files for different uses or you can create just one set for everything that the server uses SSL for. Once you create these new keystore and truststore files, specify them in the SSL configuration repertoire. See the article, Configuring Secure Sockets Layer for more information. To get to the SSL Configuration Repertoire, click Security > SSL. You can either edit the DefaultSSLConfig file or create a new SSL configuration with a new alias name. If you create a new alias name for your new keystore and truststore files, change every location that references the DefaultSSLConfig SSL configuration alias. The following list provides these locations...

    • Security > User Registries > LDAP (at the bottom of the panel)

    • Security > Authentication Protocol > CSIv2 Inbound Transport

    • Security > Authentication Protocol > CSIv2 Outbound Transport

    • Security > Authentication Protocol > SAS Inbound Transport

    • Security > Authentication Protocol > SAS Outbound Transport

    • Servers > Application Servers > application_server_name > Web Container > HTTP transports > host_link

  7. Click Security > Global Security to configure the rest of the security settings and enable security. 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. See the Global security settings article for detailed information about these fields. When you complete all of the fields, click OK or Apply to accept the selected settings. Click Save to persist these settings out to a file. If you see any informational messages in red text color, then a problem has occurred with the security validation. Typically, the message indicates the problem. So, review your configuration to verify that the user registry settings are accurate and the correct registry is selected. In some cases the LTPA configuration might not be fully specified.

  8. Store the configuration for the server to use once it restarts. Complete this action if you have clicked OK or Apply on the Security > Global Security panel, and there are no validation problems. To save the configuration, click Save in the menu bar at the top. This action writes the settings out to the configuration repository. If you do not click Apply or OK in the Global Security panel before clicking Save on the main menu, your changes are not written to the repository.

  9. Start the WebSphere Application Server administrative console by typing http://yourhost.domain:9090/admin after the WAS deployment manager has been started. If security is currently disabled, log in with any user ID. If security is currently enabled, log in with a predefined administrative ID and password, which is typically the server user ID specified when you configure the user registry.

 

See Also

Java 2 security policy files
Configuring user registries
Configuring Lightweight Third Party Authentication
Java 2 security
Global security settings