+

Search Tips   |   Advanced Search

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 WebSphere Application Server, IBM recommends installing with security enabled. By design, this option ensures that everything has been properly configured. By enabling security, you protect the server from unauthorized users and are then able to provide application isolation and requirements for authenticating application users.

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 security. The following sections help we make these decisions.

After you understand the security components, we can proceed to configure security in WebSphere Application Server.

(zos) Attention: There are some security customization tasks required to enable security. Their tasks require updates to the security server such as Resource Access Control Facility (RACF ). We might need to include the security administrator in this process.

  1. Start the WAS administrative console.

    Start the deployment manager and, in the browser, type in the address of the WAS Network Deployment server. By default, the console is located at http://your_host.your_domain:9060/ibm/console.

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

  2. Click Security > Global security.

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

    Avoid trouble: We must separately enable administrative security, and application security. Because of this split, WebSphere Application Server 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 administrative security is enabled on that server. Application security can be in effect only when administrative security is enabled.gotcha

    For more information on manual configuration, see Authenticating users.

  3. Configure the user account repository. For more information, see Select a registry or 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.

    We can choose to specify either a server ID and password for interoperability or enable a WAS installation to automatically generate an internal server ID. For more information about automatically generating server IDs, see Local operating system settings.

    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 WebSphere Application Server. 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 that 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 WebSphere Application Server processes. Rather, the process ID runs the WAS processes.

    (dist) 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 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:

    • Act as Part of Operating System privileges


    • Root privileges

    (iseries) In the default configuration, WebSphere Application Server processes run under the QEJBSVR system-provided user profile.

    (zos) When you use the stand-alone local operating system registry on WebSphere Application Server for z/OS , the user ID for the server is not set using the administrative console, but is set through the STARTED class in the z/OS operating system.

  4. 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 admin ID has been configured and is present in the active user registry. The admin 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.

  5. (zos) Optional: We can configure and change your External Authorization provider to either WebSphere Authorization, System Authorization Facility (SAF) authorization, or an external JACC provider. For more information, see z/OS System Authorization Facility authorization and Enable an external JACC provider. To change the Authorization provider, click Security > Global security.

  6. Configure the authentication mechanism.

    Configure LTPA or Kerberos, which is new to this release of WAS, under Authentication mechanisms and expiration. 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. For more information, see Configure the LTPA mechanism

    (zos) Note: We can configure SWAM as the authentication mechanism. However, SWAM was deprecated in WebSphere Application Server 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.

    If we want single sign-on (SSO) support, which provides the ability for browsers to visit different product servers without having to authenticate multiple times, see Implement single sign-on to minimize web user authentications. For form-based login, configure SSO when using LTPA.

  7. Optional: Import and export the LTPA keys for cross-cell single Sign-on (SSO) between cells. For more information, see the following articles:

    Avoid trouble: If one of the cells you are connecting to resides on a Version 6.0.x system, see the topic Configuring LTPA keys in the Version 6.0.x Information Center for more information.gotcha

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

    We can configure CSIv2 (CSIv2) through links on the Global security panel. The Security Authentication Service (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 (CSIV2) inbound and outbound communication settings.

    (zos) We can configure CSIv2 (CSIv2) through links on the Global security panel. The z/OS Security Authentication Service (z/SAS) protocol is provided for backwards compatibility with previous product releases, but is deprecated. Links to the z/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 z/SAS, see the article, Configure CSIv2 (CSIV2) inbound and outbound communication settings.

    Important: z/SAS is supported only between Version 6.0.x and previous version servers that have been federated in a Version 6.1 cell.

    Attention: IBM no longer ships or supports the Secure Authentication Service (SAS) IIOP security protocol. IBM recommends that you use the CSIv2 protocol.

    (zos) Attention: IBM no longer ships or supports the z/OS Secure Authentication Service (z/SAS) IIOP security protocol. IBM recommends that you use the CSIv2 protocol. CSIv2 will interoperate with previous versions of WAS except for the Version 4 client.

  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. The product provides a centralized location to configure SSL configurations that the various WebSphere Application Server features that use SSL can utilize, including the LDAP registry, web container and the RMI/IIOP authentication protocol (CSIv2). For more information, see Create a Secure Sockets Layer configuration. After you modify a configuration or create a new configuration, specify it on the SSL configurations panel. To get to the SSL configurations panel...

    1. Click Security > SSL certificate and key management.

    2. Under Configuration settings, click Manage endpoint security configurations > configuration_name.

    3. 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 we 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 Java Message Service (JMS), we 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).

    • Click System administration > dmgr. Under Additional properties, 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).

    • Click System administration > Node agents > node_agent _name. Under Additional properties, 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, we 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 RMI/IIOP security, click CSIv2 inbound communications.

    • Click Security > Global security. Under RMI/IIOP security, click CSIv2 outbound communications.

    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.

  10. (zos) Set the authorization. If we chose to use a z/OS security product during customization, then the authorization is by default set to use System Authorization Facility (SAF) authorization (EJBROLE profiles). Otherwise, the default is WebSphere Application Server authorization. Optionally, we can set a Java Authorization Contract for Containers (JACC) external authorization. See Special considerations for controlling access to naming roles using SAF authorization or Authorization providers.

  11. (zos) Verify the Secure Sockets Layer (SSL) repertoires for WebSphere Application Server to use. The sample customization jobs that are generated by the WebSphere z/OS Profile Management Tool or the zpmt command generate sample jobs to create SSL key rings that are usable if RACF is your security server. These jobs create a unique RACF certificate authority certificate for your installation with a set of server certificates signed by this certificate authority. The Application Server controller-started task ID has a SAF key ring that includes these certificates. Similarly in a WAS Network Deployment environment, RACF key rings that are owned by the deployment manager user ID and the node agent user IDs are created.

    A RACF key ring is uniquely identified by both the key ring name in the repertoire and the MVS™ user ID of the server controller process. If different WebSphere Application Server controller processes have unique MVS user IDs, you must be sure that a RACF key ring and a private key are generated, even if they share the same repertoire.

    Two kinds of configurable SSL repertoires exist:

    • The System SSL repertoire is used for HTTPS and Internet InterORB Protocol (IIOP) communication, and are used by the native transports. To use the administrative console after security is enabled define and select a System SSL type repertoire for HTTP. We must define a System SSL repertoire and select if IIOP security requires or supports SSL transport, or if a secure Remote Method Invocation (RMI) connector is selected for administrative requests.

    • The Java Secure Socket Extension (JSSE) repertoire is for Java-based SSL communications.

    Users must configure a System SSL repertoire to use HTTP or IIOP protocols and a JMX connector must be configured to use SSL. If the SOAP HTTP connector is chosen, a JSSE repertoire must be selected for the administrative subsystem. In a WAS Network Deployment environment, click System Administration > dmgr > Administration Services > JMX Connectors > SOAP Connector > Custom Properties > sslConfig.

    A set of SSL repertoires are set up by the z/OS installation dialogs. These dialogs are configured to refer to SAF key rings and to files that are populated by the customization process, when generating RACF commands.

    dialogs.

    This table lists the SSL repertoires that are set up by the z/OS installation dialogs.

    Repertoire name Type Default use
    (zos) NodeDefaultSSLSettings JSSE (Base only) configuration for SOAP JMX connector, SOAP client, web container HTTP transport
    (zos) CellDefaultSSLSettings JSSE (Network deployment only) configuration for SOAP JMX connector, SOAP client, web container HTTP transport
    (zos) DefaultIIOPSSL SSSL Used only if DAEMON SSL is enabled

    No additional action is required if these settings are sufficient for the needs. To create or modify these settings, you must ensure that the keystore files to which they refer are created.

  12. Click Security > Global security to configure the rest of the security settings and enable security. For information about these settings, see Global security settings.

    For additional information, see Server and administrative security.

  13. Validate the completed security configuration by clicking OK or Apply. If problems occur, they display in red type.

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

    Important: 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 administrative console.

    The save action enables the deployment manager to use the changed settings after WebSphere Application Server is restarted. For more information, see Enable security for the realm. A dmgr configuration differs from a stand-alone base application server. 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 deployment manager. Otherwise, the malfunctioning node agent does not communicate with the deployment manager after security is enabled on the deployment manager.

  15. Start the WAS administrative console.

    Start the deployment manager and, in the browser, type in the address of the WAS Network Deployment server. By default, the console is located at http://your_host.your_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 administrative ID and password. This ID is typically the server user ID specified when you configured the user registry.


Subtopics


Related concepts

  • Java 2 security
  • Multiple security domains
  • Server and administrative security

    (zos) System Authorization Facility considerations for the operating system and application levels


    Related tasks

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

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

    (zos) Server-level security settings