Enable security

By enabling security, you...

• protect the server from unauthorized users
• provide application isolation and requirements for authenticating application users

 

Security Components

1. Start the dmgr

2. In a browser, type in the address of the WAS ND server admin console...

   http://my_host.my_domain:9060/ibm/console

   If security is currently disabled, we are prompted for a user ID. Log in with any user ID. However, if security is currently enabled, we are prompted for both a user ID and a password. Log in with a predefined administrative user ID and password.

3. Click...
   Security | Global security

   Use the Security Configuration Wizard, or configure security manually. The configuration order is not important.

   You must separately enable admin 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 you attempt to enable application security on the target server, verify that admin security is enabled on that server. Application security can be in effect only when admin security is enabled.

4. Set the user account repository.

   On the Global security panel, we can configure user account repositories such as...

   • federated repositories
   • local operating system
   • standalone LDAP registry
   • standalone custom registry

   We can...

   • Specify a server ID and password for interoperability
   • Allow WAS to automatically generate an internal server ID

   The Primary administrative user name, used to log on to the admin console, is a member of the repository, but also has special privileges, The privileges for this ID and the privileges that are associated with the admin role ID are the same. The Primary administrative user name can access all of the protected admin methods.

   (Windows) 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 standalone LDAP registries, verify that the Primary administrative user name is a member of the repository and not just the LDAP admin 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 we 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:

   • (Windows) Act as Part of Operating System privileges
   • (UNIX) Root privileges

5. Select the option...

   Set as current

   ...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 admin 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 admin-authz.xml but do not exist in the current user registry.

6. Set the authentication mechanism.

   Configure LTPA or Kerberos. LTPA credentials can be forwarded to other machines. We can configure credential expiration via the console under Authentication mechanisms and expiration.

   LTPA credentials enable browsers to visit different product servers, which means you do not have to authenticate multiple times.

   Kerberos is new to this release of WAS.

   For form-based login, configure SSO when using LTPA.

7. For cross-cell SSO between cells, export and import the LTPA keys

8. Set the authentication protocol for special security requirements from Java clients, if needed.

   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.

   IBM no longer ships or supports the Secure Authentication Service IIOP security protocol. IBM recommends that you use the Common Secure Interoperability version 2 (CSIv2) protocol.

9. 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 ND v7.0 provides a centralized location to configure SSL configurations that the various WAS features that use SSL can utilize, including...

   • LDAP registry
   • Web container
   • RMI/IIOP authentication protocol (CSIv2)

   After you modify a configuration or create a new configuration, specify it on 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 we are visiting.

   We can either edit the DefaultSSLConfig file or create a new SSL configuration with a new alias name.

   If we create a new alias name for the new keystore and truststore files, change every location that references the DefaultSSLConfig SSL configuration alias.

   For 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:

   • Server | Application server | myserver | Communications Ports | transport_chain | View associated transports | transport_channel_name | Transport Channels | SSL Inbound Channel (SSL_2)
   • System administration | Deployment manager | Additional properties | Ports | transport_chain | View associated transports | transport_channel_name | Transport Channels SSL Inbound Channel (SSL_2)
   • System administration | Node agents | node_agent _name | Additional properties | Ports | transport_chain | 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 ND.

   • Security | Global security | RMI/IIOP security | CSIv2 inbound communications

   • Security | Global security | RMI/IIOP security | CSIv2 outbound communications

   For the LDAP SSL transport, we can modify the SSL configuration repertoire aliases by clicking...

   Security | Global security | User account repository | Available realm definitions drop-down list | Standalone LDAP registry

10. To configure the rest of the security settings...

    Security | Global security

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

12. If there are no validation problems, click Save to save the settings to a file that 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, the changes are not written to the repository. The server must be restarted for any changes to take effect when you start the admin console.

    The save action enables the dmgr to use the changed settings after WAS is restarted.

    A Deployment manager configuration differs from a stand-alone base application server in that the configuration is stored temporarily in the deployment manager until it is synchronized with all of the node agents.

    Also, verify that all of the node agents are up and running in the domain. 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 dmgr. Otherwise, the malfunctioning node agent does not communicate with the dmgr after security is enabled on the dmgr.

13. Start the dmgr and, in the browser, open the console...

    http://my_host.my_domain:9060/ibm/console

    If security is currently disabled, log in with any user ID. If security is currently enabled, log in with a predefined admin ID and password. This ID is typically the server user ID specified when you configured the user registry.

Administrative security
Application security
Java 2 security
Enable security for the realm
Testing security after enabling it
The Security Configuration Wizard

 

Related concepts

Java 2 security
Multiple security domains

 

Related tasks

Select a registry or repository
Set the Lightweight Third Party Authentication mechanism
Set multiple security domains

 

Related

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