Enabling security

By enabling security, you protect your server from unauthorized users and are then able to provide application isolation and requirements for authenticating application users.

Before you begin

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 you make these decisions.

Read the following article before continuing with the security configuration: After you understand the security components, you can proceed to configure security in WebSphere Application Server.
Attention: There are some security customization tasks that are required to enable security. There tasks require updates to the security server such as Resource Access Control Facility (RACF). You might need to include your security administrator in this process.
Note: For WebSphere Application Server Version 6.1, administrative security is enabled by default whenever a new profile is created, either during the initial install when you create a new profile or during post-install when you use the profile creation tooling. You can decide not to enable administrative security during profile creation time by instead enabling security post-profile creation using the administrative console.

Procedure

  1. Start the WebSphere Application Server administrative console.

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

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

  2. Click Security > Secure administration, applications, and infrastructure.

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

    Avoid trouble Avoid trouble: You 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 Selecting a registry or repository. On the Secure administration, applications, and infrastructure panel, you can configure user account repositories such as federated repositories, local operating system, standalone Lightweight Directory Access Protocol (LDAP) registry, and standalone custom registry.
    Note: You can choose to specify either a server ID and password for interoperability or enable a WebSphere Application Server 6.1 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 that are associated with the administrative role ID are the same. The Primary administrative user name can access all of the protected administrative methods.

    In standalone 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.

    When you use the standalone 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 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 you do not configure an administrative ID for the active user registry, the validation fails.
    Note: 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. Optional: You can configure and change your External Authorization provider to either WebSphere Authorization, SAF Authorization, or an external JACC provider. For more information, see z/OS System Authorization Facility authorization and Enabling an external JACC provider. To change the Authorization provider, click Security > Secure Administration, applications, and infrastructure > External Authorization providers.
  6. Configure the authentication mechanism.

    Configure Lightweight Third-Party Authentication (LTPA), which is the default authentication mechanism, on the Authentication mechanisms and expiration panel. LTPA credentials can be forwarded to other machines. For security reasons, credential expire; however, you can configure the expiration dates on the console. LTPA credentials enable browsers to visit different product servers, which means you do not have to authenticate multiple times. For more information, see Configuring the Lightweight Third Party Authentication mechanism

    Note: You can configure Simple WebSphere Authentication Mechanism (SWAM) as your authentication mechanism. However, SWAM is deprecated in WebSphere Application Server Version 6.1 and will be removed in a future release. SWAM credentials are not forwardable to other machines and for that reason do not expire. To use SWAM, select the Use SWAM-no authenticated communication between servers option. SWAM is not available in a WebSphere Application Server Network Deployment environment.

    If you want single sign-on (SSO) support, which provides the ability for browsers to visit different product servers without having to authenticate multiple times, see Implementing single sign-on to minimize Web user authentications. For form-based login, you must 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:
  8. Configure the authentication protocol for special security requirements from Java clients, if needed.
    You can configure Common Secure Interoperability Version 2 (CSIv2) through links on the Secure administration, applications, and infrastructure panel. The z/OS Secure 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 Secure administration, applications, and infrastructure panel if your environment contains servers that use previous versions of WebSphere Application Server and support the SAS protocol. For details on configuring CSIv2 or z/SAS, see the article, Configuring Common Secure Interoperability Version 2 (CSIV2) and Security Authentication Service (SAS).
    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.
    [This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] Attention: IBM no longer ships or supports the z/OS Secure Authentication Service (z/SAS) IIOP security protocol. It is recommended that you use the Common Secure Interoperability version 2 (CSIv2) protocol. CSIv2 will interoperate with previous versions of WebSphere Application Server except for the Version 4 client.
  9. Set the authorization. By default, authorization is set to WebSphere Application Server authorization to control access. Optionally, you can set either System Authorization Facility (SAF) authorization (EJBROLE profiles) or you 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.
  10. Verify the Secure Sockets Layer (SSL) repertoires for WebSphere Application Server to use. The sample customization jobs that are generated by the WebSphere Application Server for z/OS customization dialogs 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 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. If you want to use the administrative console after security is enabled you must define and select a System SSL type repertoire for HTTP. You 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 Java Management Extensions (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 Network Deployment environment, click System Administration > Deployment Manager > 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.
    Repertoire name Type Default use
    NodeDefaultSSLSettings JSSE (Base only) configuration for SOAP JMX connector, SOAP client, Web container HTTP transport
    CellDefaultSSLSettings JSSE (Network deployment only) configuration for SOAP JMX connector, SOAP client, Web container HTTP transport
    DefaultIIOPSSL SSSL Used only if DAEMON SSL is enabled

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

    If you do create a new alias for your new keystore and truststore files, change every location that references the SSL configuration alias. The following list provides these locations:
    • Security > Secure administration, applications, and infrastructure. Under RMI/IIOP security, click CSIv2 inbound transport.
    • Security > Secure administration, applications, and infrastructure. Under RMI/IIOP security, click CSIv2 outbound transport.
    • [This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] Security > Secure administration, applications, and infrastructure. Under RMI/IIOP security, click z/SAS authentication.
    • Servers > Application servers > server_name. Under Web container settings, click Web Container. Under Additional properties, click HTTP transports > host_name.
    • Servers > Application servers > server_name. Under Security, click Server security > CSIv2 inbound transport.
    • Servers > Application servers > server_name. Under Security, click Server security > CSIv2 outbound transport.
    • [This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] Servers > Application servers > server_name. Under Security, click Server security > z/SAS authentication. Select the appropriate SSL configuration from the SSL settings menu.
  11. Click Security > Secure administration, applications, and infrastructure to configure the rest of the security settings and enable security. For information about these settings, see Secure administration, applications, and infrastructure settings.

    For additional information, see Server and administrative security.

  12. 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.
  13. 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 you do not click Apply or OK in the Secure administration, applications, and infrastructure 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 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 Enabling security for the realm. A Deployment manager 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.

  14. Start the WebSphere Application Server administrative console.

    Start the deployment manager and, in your browser, type in the address of your WebSphere Application Server 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 that is specified when you configured the user registry.




In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic Task topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 12:02:36 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-zos&topic=tsec_csec2
File name: tsec_csec2.html