Configuring global security

Before you begin

It is helpful to understand security from an infrastructure standpoint 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 global security. The following sections help you make these decisions. Read the following articles before continuing with the security configuration.

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

Note: There are some security customization tasks required to enable security on WebSphere Application Server for z/OS that require updates to the security server (such as Resource Access Control Facility (RACF)) running on your system. You might need to include your security administrator in this process. Refer to Security customization dialog settings for details on customization procedures.

Steps for this task

  1. Start the WebSphere Application Server administrative console by typing http://yourhost.domain:9090/admin after the WebSphere Application Server deployment manager has been started.
    If security is currently disabled, log in with any user ID. If security is currently enabled, log in with a predefined administrative user ID and password.
  2. Click Security on the navigation menu.
    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.
  3. Configure a user registry.
    For more information, see Configuring user registries. Configure a LocalOS, LDAP, or custom user registry and then specify the details about that registry. One of these details common to all user registries is the user ID used for the server. This ID is a member of the chosen user registry, 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 user ID used for the server can access all protected administrative methods. When you use the LocalOS user 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 profile in z/OS.
  4. Configure the authentication mechanism.
    You can choose either Lightweight Third Party Authentication (LTPA), Integrated Cryptographic Services Facility (ICSF), or Simple WebSphere Authentication Mechanism (SWAM). To get details about configuring LTPA, refer to Configuring Lightweight Third Party Authentication. To get details about configuring ICSF, refer to Integrated Cryptographic Services Facility settings. LTPA and ICSF credentials are forwardable to other machines and, for security reasons, these credentials do expire. This expiration time is configurable.

    Refer to Configuring single signon if you want single signon (SSO) support, which provides the ability for browsers to visit different product servers without having to authenticate multiple times. For form-based login, you must configure SSO when using LTPA or ICSF.

  5. Configure the authentication protocol for special security requirements for Remote Method Invocation over the Internet Inter-ORB Protocol (RMI/IIOP) method invocations from Java clients or from server to server.

    Choose either the Common Secure Interoperability Version 2 (CSIv2) or Security Authentication Service (zSAS) protocol.

    The CSIv2 protocol is new to WebSphere Application Server Version 5 and has new features.

    The z/SAS protocol still provides backward compatibility to previous product releases, but is being deprecated.

    For details on configuring CSIv2 or z/SAS protocols, refer to the Configuring Common Secure Interoperability Version 2 and Security Authentication Service authentication protocols article.

  6. Verify the SSL repertoires to be used by WebSphere Application Server. The sample customization jobs generated by the WebSphere Application Server for z/OS customization dialogs create jobs that 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 user ID has a SAF key ring that includes these certificates. (Similarly in a Network Deployment environment, RACF key rings owned by the deployment manager user ID and the node agent user IDs are created.)

    Note: 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.

    There are two kinds of configurable SSL repertoires:

    • The System SSL repertoire is used for HTTPS and IIOP communication. If you want to use the administrative console after security is enabled you must define a System SSL type repertoire for HTTP and select it. You must define a System SSL repertoire and select if IIOP security requires or supports SSL transport, or if a secure RMI connector is selected for administrative requests.
    • The Java Secure Socket Extension (JSSE) repertoire is used for administrative requests if the SOAP and HTTP connector is specified (or default) and a JSSE repertoire is also required if LDAP is the selected user registry and it uses SSL for 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 (default) 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
    DefaultSSLSettings JSSE SOAP JMX connector, SOAP client
    DefaultHTTPS SSSL Web container HTTP transport
    DefaultIIOPSSL SSSL z/SAS and CSIV2
    RACFJSSESettings SSSL None
    RACFJSSESettings JSSE None


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

    For System SSL repertoires, the same key ring must be used in every System SSL repertoire used by the server.

    If you do create a new alias for your new keystore and truststore files, change every location that references the SSL configuration alias DefaultSSLConfig. The following list provides these locations:

    • Security > Authentication Protocol > CSIv2 Inbound Transport
    • Security > Authentication Protocol > CSIv2 Outbound Transport
    • Security > Authentication Protocol > zSAS Transport
    • Servers > Application Servers > app_server_name > Web Container > HTTP transports > host_link
    • Servers > Application Servers > app_server_name > Server Level Security > CSIv2 Inbound Transport
    • Servers > Application Servers > app_server_name > Server Security > CSIv2 OutboundTransport
    • Servers > Application Servers > app_server_name > Server Security > zSAS Inbound Transport> ssl settings
    • Servers > Application Servers > app_server_name > Server Security > zSAS Outbound Transport > ssl settings

  7. Click Security > Global Security to configure the rest of the security settings and to enable security.

    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. See the Global security and server security article for detailed information.

    Enabled
    This flag enables or disables global security. See the Global security and server security article to learn more about 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
    This flag enables or disables Java 2 security access control. See Configuring Java 2 security for details on Java 2 security in WebSphere Application Server, Version 5.
    Use Domain Qualified User IDs
    This flag determines 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 WebSphere Application Server 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.
    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. WebSphere Application Server provides support for policy file management. A number of policy files exist in WebSphere Application Server; some of the policy files are static and some of them are dynamic. Dynamic policy is a template of permissions for a particular type of resource. No code base is defined and no related code base is used in the dynamic policy template. The real code base is dynamically created from the 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. For more information on permissions, see the Java 2 security policy files (Dynamic Policy) article.
    Active Protocol
    This flag selects the active authentication protocol for the object request broker (ORB). RMI/IIOP requests use this protocol to gather security information in a format that both client and server understands. In step 5 , you already might have configured one or both of these authentication protocols. Select BOTH, if you need to communicate with WebSphere Application Server Version 5 and previous versions. Select CSI, if you only need to communicate with WebSphere Application Server Version 5 servers.
    Active Authentication Mechanism
    WebSphere Application Server for z/OS, Version 5 supports the following authentication mechanisms: Simple WebSphere Authentication Mechanism (SWAM), Lightweight Third Party Authentication (LTPA), and Integrated Cryptographic Services Facility (ICSF).
    Active User Registry
    This flag indicates the user registry you that chose in step 3. The Configuring user registries article provides the necessary steps to configure the user registry.
  8. Store the configuration for the deployment manager to use after the WebSphere Application Server 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 application server. 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 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.

    Important: If security is enabled on a WebSphere Application Server 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. You should create your own trust stores and key stores for production systems (default ones are suggested only for testing purposes).

    1. Copy ..\DeploymentManager\etc\Dummy*File.jks ( there are four of them) to ..\AppServer\etc. Make sure you save the original ones before the copy.
    2. Recycle the Network Deployment (ND) server and perform the sync operation again.


Related concepts
Synchronizing a Java thread identity and an operating system thread identity
Java 2 security policy files
Related tasks
Configuring user registries
Configuring Lightweight Third Party Authentication
Related reference
Java 2 security
Global security settings
Server security settings
Server-level security settings



Searchable topic ID:   tseccsec
Last updated: Jun 21, 2007 9:56:50 PM CDT    WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/tsec_csec.html

Library | Support | Terms of Use | Feedback