Configure global security

 

+

Search Tips   |   Advanced Search

 

Overview

The procedure lists all of the tasks required to set up security. Note that not all of the tasks are required. For example, you might just want to lock down the console, and leave applications unauthenicated. Or you want to want to configure SSL and trust association interceptors. Implementation of each task should take place within the broader context of general security architecture planning.

 

Procedure

  1. Configure a user registry.

    1. LocalOS
    2. LDAP
    3. Custom user registry

    For custom user registries, code should not use data sources to connect directly to a database, rather, use JDBC providers to connect to the database.

  2. Assign users to administrative roles and configure any required console users and/or console groups.

    Console | System Administration | Console Users

    For each type of user registry, a server user ID must be configured. 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 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 LTPA.

  4. If required, disable server security using the server level security enable flag

    For example, you might want to lock people out of the console, but still allow unauthenticated access to applications. You can do this by enabling global security, and then disabling security on the server level.

    While appserver security is disabled for user requests, administrative and naming security is still enabled for that application server so that the administrative and naming infrastructure remains secure. If cell security is enabled, but security for individual servers is disabled, J2EE applications are not authenticated or authorized. However, naming and administrative security is still enforced.

    Because naming services can be called from user applications you need to grant Everyone access to the naming functions that are required so that these functions accept unauthenticated requests. User code does not directly access administrative security except through the supported scripting tools.

  5. Configure single signon.

    The LTPA authentication mechanism requires that you enable SSO if any of the Web applications have form login as the authentication method.

    The default configuration should be sufficient for most configurations.

  6. If required, Assign users to naming roles.

  7. Configure Java Authentication and Authorization Service login.

  8. CSIv2 and SAS authentication protocols.

  9. Configure Secure Sockets Layer.

  10. Configure trust association interceptors.

  11. Configure security attribute propagation.

  12. Configure the authentication protocol for special security requirements for RMI/IIOP method invocations from Java clients or from server to server. Choose either the CSIv2 or SAS protocol.

  13. Configure Java 2 Security Manager.

  14. If required, 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.

    You can create different keystore and truststore files for different uses or create one set for everything that involves the server use of SSL.

    After creation, specify them in the SSL Configuration Repertoires by clicking "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"...

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

  15. Click...

    Security | Global Security

    ...to configure the rest of the security settings and to enable security.

    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.

    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.

    Enabled

    Enable/disable 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

    Enable/disable Java 2 security access control.

    Use Domain Qualified User IDs

    Determine 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 WAS 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. Currently, no way is available to flush the cache or purge specific users from the cache.

    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. WAS provides support for policy file management.

    With dynamic policy files no code base is defined, rather, the code base is dynamically created from 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.

    Active Protocol

    Select the active authentication protocol for the object request broker. RMI/IIOP requests use this protocol to gather security information in a format that both client and server understands.

    Select BOTH, if you need to communicate with WAS 5.x and previous versions.

    Select CSI, if you only need to communicate with WAS 5.x servers.

    Active Authentication Mechanism

    LTPA is the default.

    Active User Registry

    Indicate the user registry previously.

  16. Store the configuration for the deployment manager to use after the WAS 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 appserver. 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 appservers 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 WAS 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. Create your own trust stores and key stores for production systems (default ones are suggested only for testing purposes).

    1. Make copies...

      cp $ND_HOME/AppServer/etc/Dummy*File.jks /backup/directory
      cp $ND_HOME/DeploymentManager/etc/Dummy*File.jks $ND_HOME/AppServer/etc

    2. Cycle the Network Deployment server and perform the sync operation again.

  17. If you have problems accessing applications or the console, see...

 

See also

  1. Welcome to security
  2. Planning to secure your environment
  3. Global security and server security
  4. Errors when trying to configure or enable security
  5. Global security
  6. Global security and server security
  7. Administrative console and naming service authorization
  8. Authentication mechanisms
  9. User registries
  10. Java Authentication and Authorization Service
  11. Identity mapping
  12. Security attribute propagation
  13. Authentication protocol for EJB security
  14. Secure Sockets Layer
  15. Default PropagationToken
  16. Default AuthorizationToken
  17. Default SingleSignonToken
  18. Default AuthenticationToken
  19. Cryptographic token support
  20. Java 2 security