WebSphere Application Server - Express, Version 6.0.x     Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Configuring global security

Before you begin

It is helpful to understand security from an infrastructure perspective 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

  1. Start the WebSphere Application Server administrative console by clicking http://yourhost.domain:9060/ibm/console after starting the WebSphere Application Server. 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 > Global security and configure the authentication mechanism, user registry, and so on. The configuration order is not important. However, when you select the Enable global security option in the Global security panel, verify that all these tasks are completed. When you click Apply or OK and the Enable global security option 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 configure these, the validation fails.
  3. Configure a user registry. For more information, see Configuring user registries. You can configure a local OS, Lightweight Directory Access Protocol (LDAP), or custom user registry through the links under User registry on the Global security panel.

    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 WebSphere Application Server. The privileges for this ID and the privileges that are associated with the administrative role ID are the same. The server user ID can access all the protected administrative methods.

    [Windows]The ID must not be the same name as the machine name of your system because the user 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 user registry and not just the LDAP administrative role ID. The entry must be searchable.

    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 running as a service, the user ID that is logged into the system is the user ID running the service. If you choose the Local OS user registry, the process ID requires special privileges to call the operating system APIs. The process ID must have the following platform-specific privileges:
    • [Windows]Act as Part of Operating System privileges
    • [UNIX]Root privileges
  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 Common Secure Interoperability Version 2 (CSIv2) or Security Authentication Service (SAS). 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 Common Secure Interoperability Version 2 and Security Authentication Service authentication protocols.
    Attention: In future releases, IBM will no longer ship or support the Secure Authentication Service (SAS) IIOP security protocol. It is suggested that you use the Common Secure Interoperability version 2 (CSIv2) protocol.
  6. Modify the default Secure Sockets Layer (SSL) keystore and truststore files that are packaged with the product. This action protects the integrity of the messages sent across the Internet. The product provides a single location where you can specify SSL configurations that the various WebSphere Application Server 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 a keystore file 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 Secure Sockets Layer (SSL) for. After 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. 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 specifies the locations of where the SSL configuration repertoire aliases are used in the WebSphere Application Server configuration.
    For any transports that use the new network input/output channel chains, including HTTP and Java Message Service (JMS), you can modify the SSL configuration repertoire aliases in the following locations for each server:
    • Click Server > Application server > server_name. Under Communications, click Ports. Locate a transport chain where SSL is enabled and click View associated transports. Click transport_channel_name. Under Transport Channels, click SSL Inbound Channel (SSL_2).
    For the Object Request Broker (ORB) SSL transports, you can modify the SSL configuration repertoire aliases in the following locations. These configurations are for the server-level for WebSphere Application Server and WebSphere Application Server Express and the cell level for WebSphere Application Server Network Deployment.
    • Click Security > Global security. Under Authentication, click Authentication protocol > CSIv2 Inbound Transport.
    • Click Security > Global security. Under Authentication, click Authentication protocol > CSIv2 Outbound Transport.
    • Click Security > Global security. Under Authentication, click Authentication protocol > SAS Inbound Transport.
    • Click Security > Global security. Under Authentication, click Authentication protocol > SAS Outbound Transport.

    For the Simple Object Access Protocol (SOAP) Java Management Extensions (JMX) administrative transports, you can modify the SSL configurations repertoire aliases by clicking Servers > Application servers > server_name. Under Server infrastructure, click Administration > Administration services. Under Additional properties, click JMX connectors > SOAPConnector. Under Additional properties, click Custom properties. If you want to point the sslConfig property to a new alias, click sslConfig and select an alias in the Value field.

    For the Lightweight Directory Access Protocol (LDAP) SSL transport, you can modify the SSL configuration repertoire aliases by clicking Security > Global security. Under User registries, click LDAP.

  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; therefore, 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 after 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:9060/ibm/console after the WebSphere Application Server 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.



Sub-topics
Enabling global security

Related concepts
Java 2 security policy files

Related tasks
Configuring user registries
Configuring Lightweight Third Party Authentication

Related reference
Java 2 security
Global security settings

Task topic    

Terms of Use | Feedback

Last updated: Jun 8, 2005 12:45:23 PM EDT
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tsec_csec.html

© Copyright IBM Corporation 2002, 2005. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)