WAS v8.5 > Secure applications > Set up security

Enable security

The following provides information on how to configure security when security was not enabled during the WebSphere Application Sever profile creation.

When you are installing WAS, IBM recommends that you install with security enabled. By design, this option ensures that everything has been properly configured. By enabling security, you protect your server from unauthorized users and are then able to provide application isolation and requirements for authenticating application users.

  1. Start the dmgr console and go to...

      Security | Global security

    Use the Security Configuration Wizard, or configure security manually.

    The configuration order is not important.

    Separately enable administrative security, and application security. Because of this split, WAS clients must know whether application security is disabled at the target server. Administrative security is enabled, by default. Application security is disabled, by default.

    Before enabling application security on the target server, verify that administrative security is enabled on that server. Application security can be in effect only when administrative security is enabled.

  2. Configure the user account repository.

    On the Global security panel, we can configure user account repositories such as federated repositories, local operating system, stand-alone LDAP registry, and stand-alone custom registry.

    Choose to specify either a server ID and password for interoperability or enable a WAS installation to automatically generate an internal server ID.

    One of the details common to all user registries or repositories is the Primary administrative user name. This ID is a member of the chosen repository, 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 Primary administrative user name can access all of the protected administrative methods.

    The ID must not be the same name as the machine name of the system because the repository sometimes returns machine-specific information when querying a user of the same name.

    In stand-alone LDAP registries, verify the Primary administrative user name is a member of the repository and not just the LDAP administrative role ID. The entry must be searchable.

    The Primary administrative user name 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 we 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 operating system registry, the process ID requires special privileges to call the operating system APIs. The process ID must have the following platform-specific privileges:

    • Act as Part of Operating System privileges
    • Root privileges

  3. Select the Set as current option after you configure the user account repository.

    When you click Apply and the Enable administrative security option is set, a verification occurs to see if an administrative user ID has been configured and is present in the active user registry. The administrative user ID can be specified at the active user registry panel or from the console users link. If we do not configure an administrative ID for the active user registry, the validation fails.

    When you switch user registries, the admin-authz.xml file should be cleared of existing administrative ids and application names. Exceptions will occur in the logs for ids that exist in the admin-authz.xml file but do not exist in the current user registry.

  4. Configure the authentication mechanism.

    See Lightweight Third-Party Authentication (LTPA) or Kerberos.

    LTPA credentials can be forwarded to other machines. For security reasons, credential expire; however, we can configure the expiration dates on the console. LTPA credentials enable browsers to visit different product servers, which means we do not have to authenticate multiple times.

    We can configure Simple WebSphere Authentication Mechanism (SWAM) as your authentication mechanism. However, SWAM was deprecated in WAS v8.5 and will be removed in a future release. SWAM credentials are not forwardable to other machines and for that reason do not expire.

  5. Optional: Import and export the LTPA keys for cross-cell single Sign-on (SSO) between cells. See...

    If one of the cells you are connecting to resides on a v6.0.x system, see the topic Configuring LTPA keys in the v6.0.x Information Center for more information.

  6. Configure the authentication protocol for special security requirements from Java clients, if needed.

    We can configure CSIv2 through links on the Global security panel. The SAS protocol is provided for backwards compatibility with previous product releases, but is deprecated. Links to the SAS protocol panels display on the Global security panel if the environment contains servers that use previous versions of WAS and support the SAS protocol. For details on configuring CSIv2 or SAS, see the article, Configure CSIV2 inbound and outbound communication settings.

    IBM no longer ships or supports the Secure Authentication Service (SAS) IIOP security protocol. It is recommended that we use the Common Secure Interoperability version 2 (CSIv2) protocol.

  7. Secure Socket Layers (SSL) is pre-configured by default, changes are not necessary unless we have custom SSL requirements.

    We can modify or a create a new SSL configuration. This action protects the integrity of the messages sent across the Internet. WAS v8.5 provides a centralized location to configure SSL configurations the various WAS features that use SSL can utilize, including the LDAP registry, web container and the RMI/IIOP authentication protocol (CSIv2). After you modify a configuration or create a new configuration, specify it on the SSL configurations panel. To get to the SSL configurations panel...

      Security | SSL certificate and key management | Configuration settings | Manage endpoint security configurations | configuration_name

    Under Related items for each scope (for example, node, cluster, server), select one of the many configuration links that can be scoped to the resource you are visiting.

    We 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 the 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 WAS configuration.

    For any transports that use the new network input/output channel chains, including HTTP and JMS, we can modify the SSL configuration repertoire aliases in the following locations for each server, click...

      Server | Application server | server_name | Communications | Ports

    Locate a transport chain where SSL is enabled and click...

      View associated transports | transport_channel_name | Transport Channels | SSL Inbound Channel (SSL_2)

    For the ORB SSL transports, we can modify the SSL configuration repertoire aliases in the following locations. These configurations are for the server-level for WAS and WAS, Express and the cell level for WAS, Network Deployment. Click...

    For the LDAP SSL transport, we can modify the SSL configuration repertoire aliases by clicking Security > Global security. Under User account repository, click the Available realm definitions drop-down list, and select Standalone LDAP registry.

  8. To configure the rest of the security settings and enable security, click...

  9. Validate the completed security configuration by clicking OK or Apply.

    If problems occur, they display at the top of the console page in red type.

  10. If there are no validation problems, click Save to save the settings to a file the server uses when it restarts.

    Saving writes the settings to the configuration repository.

    If we do not click Apply or OK in the Global security panel before you click Save, your changes are not written to the repository. The server must be restarted for any changes to take effect when we start the dmgr console.

  11. Start the dmgr console.

    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 ID is typically the server user ID specified when we configured the user registry.


Subtopics


Related concepts:

Java 2 security
Multiple security domains


Related


Select a registry or repository
Configure the LTPA mechanism
Configure multiple security domains


Reference:

Java 2 security policy files
Global security settings
Specify extent of protection wizard settings


+

Search Tips   |   Advanced Search