The following provides information on how to configure
security when security was not enabled during the WebSphere® Application Sever profile creation.
Before you begin
When you are installing WebSphere Application
Server, it is recommended that you install with security enabled.
By design, this option ensures that everything has been properly configured.
By enabling security, you protect your 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 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 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.
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.
- Click Security > Global security.
Use
the Security Configuration Wizard, or configure security manually.
The configuration order is not important.
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.
- Configure the user account repository. For
more
information, see Selecting a registry or repository.
On the Global security panel, you can configure user account repositories
such as federated repositories, local operating system, stand-alone
Lightweight Directory Access Protocol (LDAP) registry, and stand-alone
custom registry.
Note: You can choose to specify either a server ID
and password for interoperability or enable a
WebSphere Application Server 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 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.
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.
- 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.
-
Optional: You 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 Enabling an external JACC provider. To change the Authorization
provider, click Security > Global security.
-
Configure the authentication mechanism.
Configure
Lightweight Third-Party Authentication (LTPA) or Kerberos, which is
new to this release of WebSphere Application Server,
under Authentication mechanisms and expiration. 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 was
deprecated in WebSphere Application Server Version 8.0 and will be removed
in a future release. SWAM credentials are not forwardable to other
machines and for that reason do not expire.
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.
- 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 Lightweight Third Party Authentication keys in the Version
6.0.x Information Center for more information.
gotcha
- 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 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 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) 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 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.
- Set the authorization. If
you 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, 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.
- 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 WebSphere Application Server, 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 WebSphere Application Server, 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.
Table 1. SSL
repertoires set up the z/OS installation
dialogs. This table lists the SSL repertoires that
are set up by the z/OS installation
dialogs.
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.
- 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.
- 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.
- 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 Global security 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.
- 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.