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.
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 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 > Global security. Under Authentication, click Authentication
protocol > CSIv2 inbound transport.
- Security > Global security. Under Authentication, click Authentication
protocol > CSIv2 outbound transport.
- Security > Global security. Under Authentication, click Authentication
protocol > zSAS 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. Under Additional properties, click CSIv2
inbound transport.
- Servers > Application servers > server_name. Under Security,
click Server security. Under Additional properties, click CSIv2
outbound transport.
- Servers > Application servers > server_name.
Under Security, click Server security. Under Additional properties,
click z/SAS authentication. Select the appropriate SSL configuration
from the SSL settings menu.
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, a problem exists with the security validation. Typically, the
message indicates the problem. Review your configuration to verify that the
user registry settings are accurate and that the correct user registry is
selected. In some cases, the Lightweight Third Party Authentication (LTPA)
configuration might not be fully specified. See Server and global security for detailed information.
- Enable global security
- This option enables or disables global security. See Server and global security 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 option enables or disables Java 2 security access control. See Protecting system resources and APIs (Java 2 security) for
details on Java 2 security in WebSphere Application Server.
- Use Domain Qualified User IDs
- This option determines if user IDs that are returned by the J2EE APIs
such as getUserPrincipal and getCallerPrincipal are qualified within the security
domain in which they reside.
- Cache Timeout
- The field 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. Currently, no way is available
to flush the cache or purge specific users from the cache.
- Issue Permission Warning
- When you enable this option, 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 does not have according to the J2EE 1.3 specification.
For more information on permissions, see Java 2 security policy files.
- Active Protocol
- This selection is 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 the client and the server understand. In step 5, you
might have already configured one or both of these authentication protocols.
Select BOTH, if you need to communicate with versions of WebSphere
Application Server prior to Version 5. Select CSI, if you need to communicate
with WebSphere Application Server Version 5.x or Version 6.0.x servers only.
- Active Authentication Mechanism
- This selection determines which authentication mechanism WebSphere Application
Server for z/OS uses. WebSphere Application Server for z/OS Version 6.0.x
supports the following authentication mechanisms: Simple WebSphere Authentication
Mechanism (SWAM) or Lightweight Third Party Authentication (LTPA), which is
the preferred.
- Active User Registry
- This option indicates the user registry that you chose in step 3. The Selecting a user registry article
provides the necessary steps to configure the user registry.
- Use the Federal Information Processing Standard (FIPS)
- This option enables the FIPS-compliant Java cryptography engine.