After determining the security components that fit your needs,
use these steps to configure global security in WebSphere Application Server.
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 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.
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.
Start
the WebSphere Application Server administrative console by clicking http://yourhost.domain:port_number/ibm/console after
starting the WebSphere Application Server. 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.
Click Security
> Global security and configure the authentication mechanism, user registry,
and so on. The configuration order is not important. However,
when you select the Enable global security option in the Global security
panel, verify that all these tasks are completed. When you click Apply or OK 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.
Configure
a user registry. For more information, see Selecting a user registry. You can configure a local OS,
Lightweight Directory Access Protocol (LDAP), or custom user registry through
the links under User registry on the Global security panel.One of the details
common to all user registries is the server user ID. 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 that are
associated with the administrative role ID are the same. The server user ID
can access all the protected administrative methods.
The
ID must not be the same name as the machine name of your system because the
user registry sometimes returns machine-specific information when querying
a user of the same name.
In LDAP user registries, verify that the server
user ID is a member of the user registry and not just the LDAP administrative
role ID. The entry must be searchable.
The server
user ID does not run WebSphere Application Server processes. Rather,
the process ID runs the WebSphere Application Server processes.
Configure
the authentication mechanism. To get details about configuring
authentication mechanisms, read the Selecting an authentication mechanism article. There are two authentication
mechanisms to choose from in the Global Security panel: Simple WebSphere Authentication
Mechanism (SWAM) and Lightweight Third-Party Authentication (LTPA). However,
only LTPA requires any additional configuration parameters. Use the SWAM option
for single server requirements. Use the LTPA option for multi-server distributed
requirements. SWAM credentials are not forwardable to other machines and for
that reason do not expire. Credentials for LTPA are forwardable to other machines
and for security reasons do expire. This expiration time is configurable.
If you choose to go with LTPA, then Implementing single sign-on to minimize Web user authentications support. This support permits browsers to visit different
product servers without having to authenticate multiple times.
Configure
the authentication protocol for special security requirements from Java clients,
if needed. This task entails choosing a protocol, either Common
Secure Interoperability Version 2 (CSIv2) or Security Authentication Service
(SAS). The SAS protocol is still provided for backwards compatibility to previous
product releases, but is being deprecated. For details on configuring CSIv2
or SAS, see the article, Configuring Common Secure Interoperability Version 2 (CSIV2) and Security Authentication Service (SAS). Attention: In future
releases, IBM will no longer ship or support the Secure Authentication Service
(SAS) IIOP security protocol. It is suggested that you use the Common Secure
Interoperability version 2 (CSIv2) protocol.
Modify
the default Secure Sockets Layer (SSL) keystore and truststore files that
are packaged with the product. This action protects the integrity
of the messages sent across the Internet. The product provides a single location
where you can specify SSL configurations that the various WebSphere Application
Server features that use SSL can utilize, including the LDAP user registry,
Web container and the authentication protocol (CSIv2 and SAS). Create a new
keystore and truststore, by referring to the Creating a keystore file and Creating truststore files articles.
You can create different keystore files and truststore files for different
uses or you can create just one set for everything that the server uses Secure
Sockets Layer (SSL) for. After you create these new keystore and truststore
files, specify them in the SSL Configuration Repertoires. To get to
the SSL Configuration Repertoires, click Security > SSL. See
the article, Configuring Secure Sockets Layer (SSL) for more information. To get to the SSL Configuration
Repertoire, click Security > SSL. You can either edit the DefaultSSLConfig
file or create a new SSL configuration with a new alias name. If you create
a new alias name for your 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 WebSphere Application Server configuration. For
any transports that use the new network input/output channel chains, including
HTTP and Java Message Service (JMS), you can modify the SSL configuration
repertoire aliases in the following location for each server:
For the Object Request Broker (ORB) SSL transports, you can modify
the SSL configuration repertoire aliases in the following locations.
- Click Security > Global security. Under Authentication, click Authentication
protocol > CSIv2 Inbound Transport.
- Click Security > Global security. Under Authentication, click Authentication
protocol > CSIv2 Outbound Transport.
- Click Security > Global security. Under Authentication,
click Authentication protocol > SAS Inbound Transport.
- Click Security > Global security. Under Authentication,
click Authentication protocol > SAS Outbound Transport.
For the Simple Object Access Protocol (SOAP) Java Management Extensions
(JMX) administrative transports, you can modify the SSL configurations repertoire
aliases by clicking Servers > Application servers > server_name.
Under Server infrastructure, click Administration > Administration services.
Under Additional properties, click JMX connectors > SOAPConnector.
Under Additional properties, click Custom properties. If you want to
point the sslConfig property to a new alias, click sslConfig and select
an alias in the Value field.
For the Lightweight Directory Access Protocol (LDAP) SSL transport,
you can modify the SSL configuration repertoire aliases by clicking Security
> Global security. Under User registries, click LDAP.
Click Security > Global
security to configure the rest of the security settings and 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.
See the Global security settings article
for detailed information about these fields. When you complete all of the
fields, click OK or Apply to accept the selected settings. Click Save to
persist these settings out to a file. If you see any informational messages
in red text color, then a problem has occurred with the security validation.
Typically, the message indicates the problem; therefore, review your configuration
to verify that the user registry settings are accurate and the correct registry
is selected. In some cases the LTPA configuration might not be fully specified.
Store
the configuration for the server to use after it restarts. Complete this action
if you have clicked OK or Apply on the Security > Global
security panel, and there are no validation problems. To save the configuration,
click Save in the menu bar at the top. This action writes the settings
out to the configuration repository. If you do not click Apply or OK in
the Global security panel before clicking Save on the main menu,
your changes are not written to the repository.
Start the WebSphere Application
Server administrative console by typing http://yourhost.domain:port_number/ibm/console 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 ID and password,
which is typically the server user ID specified when you configure the user
registry.
Start the WebSphere Application
Server administrative console by typing http://yourhost.domain:port_number/ibm/console 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.
Click Security on the navigation
menu. Configure the authentication mechanism, user registry, and
so on. The configuration order is not important. However, select the Enable
global security option in the Global Security panel after you complete
all of these tasks. When you first click Apply or OK and the Enable
global security option 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.
Configure a user registry.
For more information, see Selecting a user registry. Configure a Local OS, Lightweight Directory Access Protocol
(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 that is
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 that are associated with the administrative
role ID are the same. The user ID that is used for the server can access all
protected administrative methods. When you use the Local OS 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 class
in the z/OS operating system.
Configure the Authentication
Mechanism. In the WebSphere Application Server Network Deployment
package, Lightweight Third Party Authentication (LTPA) is the only authentication
mechanism supported. To get details about configuring LTPA, go to the Configuring the Lightweight Third Party Authentication mechanism article. LTPA
credentials are forwardable to other machines and for security reasons do
expire. This expiration time is configurable. See the Implementing single sign-on to minimize Web user authentications article, 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. For form-based
login, you must configure SSO when using LTPA.
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 the Lightweight Third Party Authentication mechanism. To get details about configuring ICSF, refer to
Configuring ICSF as the authentication mechanism. LTPA and ICSF credentials
are forwardable to other machines and, for security reasons, these credentials
do expire. This expiration time is configurable. Refer to Implementing single sign-on to minimize Web user authentications 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. For form-based login, you must
configure SSO when using LTPA or ICSF .
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 the Common Secure Interoperability Version
2 (CSIv2) or Secure Authentication Service (SAS) protocol or the z/OS Secure
Authentication Service (z/SAS) protocol on the z/OS platform. The SAS and
z/SAS protocols still provide backward compatibility to previous product releases.
For details on configuring CSIv2, SAS, or z/SAS protocols, refer to
Configuring Common Secure Interoperability Version 2 (CSIV2) and Security Authentication Service (SAS).
Attention: In future releases, IBM will no longer
ship or support the z/OS Secure Authentication Service (z/SAS) IIOP security
protocol. Use the Common Secure Interoperability version 2 (CSIv2) protocol
instead. CSIv2 will interoperate with previous versions of WebSphere except
for the Version 4 Client.
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.
Save the configuration for the
deployment manager to use after WebSphere Application Server is restarted,
if you have selected OK or Apply on the Security > Global
security panel, and no validation problems occurred.