Configuring global security

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

  1. Click Security on the navigation menu.
    Configure the authentication mechanism, user registry, and so on. The configuration order is not important. However, select the Enabled flag in the Global Security panel after you have completed all of these tasks. When you first 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 the user registry is not configured, the validation fails.
  2. Configure a user registry.
    For more information, see Configuring user registries. Configure a LocalOS, LDAP, or custom user registry and then specify the details about that registry. One of these 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 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 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.

  3. Configure the Authentication Mechanism.
    In the WebSphere Application Server Network Deployment package, Lightweight Third Party Authentication (LTPA) is the only authentication mechanism supported. To get details about configuring LTPA, go to the Configuring Lightweight Third Party Authentication article. LTPA credentials are forwardable to other machines and for security reasons do expire. This expiration time is configurable. See the Configuring single signon article, 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.
  4. Configure the authentication protocol for special security requirements for Remote Method Invocation over the Internet Inter-ORB Protocol (RMI/IIOP) method invocations from Java clients or from server to server.

    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.

  5. Change the default SSL keystore and truststore files that are packaged with the product.

    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:

    • 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 > app_server_name > Web Container > HTTP transports > host_link
    • Servers > Application Servers > app_server_name > Server Level Security > CSIv2 Inbound Transport
    • Servers > Application Servers > app_server_name > Server Security > CSIv2 OutboundTransport
    • Servers > Application Servers > app_server_name > Server Security > SAS Inbound Transport
    • Servers > Application Servers > app_server_name > Server Security > SAS Outbound Transport

  6. Click Security > Global Security to configure the rest of the security settings and to 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. 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.

    Enabled
    This flag enables or disables global security. See the Global security and server security article to learn more about global security. When enabled, security for the entire product domain is enabled. You can change some security attributes at a server-specific level.
    Enforce Java 2 Security
    This flag enables or disables Java 2 security access control. See Configuring Java 2 security for details on Java 2 security in WebSphere Application Server, Version 5.
    Use Domain Qualified User IDs
    This flag determines if user IDs returned by the J2EE APIs such as getUserPrincipal() and getCallerPrincipal() are qualified within the security domain in which they reside.
    Cache Timeout
    The flag is the timeout value of the WebSphere Application Server authentication and validation cache. This value is used to determine when to flush a credential from the cache. Any time that the credential is reused, the cache timeout for that credential is reset to this value.
    Issue Permission Warning
    When you enable this flag, a warning is issued during application installation if an application requires a Java 2 security permission that normally is not granted to an application. WebSphere Application Server provides support for policy file management. A number of policy files exist in WebSphere Application Server; some of the policy files are static and some of them are dynamic. Dynamic policy is a template of permissions for a particular type of resource. No code base is defined and no related code base is used in the dynamic policy template. The real code base is dynamically created from the configuration and run-time data. The filter.policy file contains a list of permissions that an application should not have according to the J2EE 1.3 specification. For more information on permissions, see the Java 2 security policy files (Dynamic Policy) article.
    Active Protocol
    This flag selects the active authentication protocol for the object request broker (ORB). RMI/IIOP requests use this protocol to gather security information in a format that both client and server understands. In step 5 , you already might have configured one or both of these authentication protocols. Select BOTH, if you need to communicate with WebSphere Application Server Version 5 and previous versions. Select CSI, if you only need to communicate with WebSphere Application Server Version 5 servers.
    Active Authentication Mechanism
    There are three authentication mechanisms to choose from: Integrated Cryptographic Services Facility (ICSF) and Lightweight Third-Party Authentication (LTPA).
    Active User Registry
    This flag indicates the user registry you that chose in step 3. The Configuring user registries article provides the necessary steps to configure the user registry.
  7. Store the configuration for the deployment manager to use after the WebSphere Application Server is restarted, if you have selected OK or Apply on the Security > Global Security panel, and no validation problems occurred.

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

    1. Copy ..\DeploymentManager\etc\Dummy*File.jks ( there are four of them) to ..\AppServer\etc. Make sure you save the original ones before the copy.
    2. Recycle the Network Deployment (ND) server and perform the sync operation again.


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
Server security settings
Server-level security settings



Searchable topic ID:   tseccsec
Last updated: Jun 21, 2007 4:55:42 PM CDT    WebSphere Application Server Network Deployment, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tsec_csec.html

Library | Support | Terms of Use | Feedback