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.
- 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 > 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: 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 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.
The
ID must not be the same name as the machine name of your system because the
repository sometimes returns machine-specific information when querying a
user of the same name.
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.
The
Primary administrative user name does not run WebSphere Application
Server processes. Rather, the process ID runs the WebSphere Application Server
processes.
![[AIX HP-UX Linux Solaris Windows]](../../dist.gif)
The
process ID is determined by the
way the process starts. For example, if you use a command line to start processes,
the user ID that is logged into the system is the process ID. If running as
a service, the user ID that is logged into the system is the user ID running
the service. If you choose the local operating system registry, the process
ID requires special privileges to call the operating system APIs. The process
ID must have the following platform-specific privileges:
Act as Part of Operating System privileges
Root privileges
In the default configuration, WebSphere Application
Server processes run under the QEJBSVR system-provided user profile.
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.
- 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, 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.
- 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.
- Optional: Import and export the LTPA
keys for cross-cell single Sign-on (SSO) between cells. For more
information, see the following articles:
- Configure the authentication protocol for special security requirements
from Java clients, if needed.
![[i5/OS]](../../iseries.gif)
You can
configure Common Secure Interoperability Version 2 (CSIv2) through links on
the Secure administration, applications, and infrastructure panel. The Secure
Authentication Service (SAS) protocol is provided for backwards compatibility
with previous product releases, but is deprecated. Links to the 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 SAS, see the article,
Configuring Common Secure Interoperability Version 2 (CSIV2) and Security Authentication Service (SAS).
Important: SAS is supported only between Version 6.0.x and previous version servers that have been federated in a Version 6.1 cell.
![[z/OS]](../../ngzos.gif)
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.
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.
Modify or a create a default Secure Sockets Layer (SSL) configuration.
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 registry, Web container and the authentication protocol
(CSIv2 and SAS). For more information, see Creating a Secure Sockets Layer configuration. After you modify a configuration or create a new configuration,
specify it on the SSL configurations panel. To get to the SSL configurations
panel, complete the following steps:
- Click Security > SSL certificate and key management.
- Under Configuration settings, click Manage endpoint security configurations
> configuration_name.
- Under Related items, click SSL configurations.
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 locations for each server:
- Click Server > Application server > server_name. Under Communications,
click Ports. Locate a transport chain where SSL is enabled and click View
associated transports. Click transport_channel_name. Under Transport
Channels, click SSL Inbound Channel (SSL_2).
- Click System
administration > Deployment manager. Under Additional properties, click Ports.
Locate a transport chain where SSL is enabled and click View associated
transports. Click transport_channel_name. Under Transport Channels,
click SSL Inbound Channel (SSL_2).
- Click System
administration > Node agents > node_agent _name. Under Additional
properties, click Ports. Locate a transport chain where SSL is enabled
and click View associated transports. Click transport_channel_name.
Under Transport Channels, click SSL Inbound Channel (SSL_2).
For the Object Request Broker (ORB) SSL transports, you can modify
the SSL configuration repertoire aliases in the following locations. These
configurations are for the server-level for WebSphere Application Server and
WebSphere Application Server Express and the cell level for WebSphere Application
Server Network Deployment.
- Click Security > Secure administration, applications, and infrastructure.
Under RMI/IIOP security, click CSIv2 inbound transport.
- Click Security > Secure administration, applications, and infrastructure.
Under RMI/IIOP security, click CSIv2 outbound transport.
Click Security > Secure administration, applications,
and infrastructure. Under RMI/IIOP security, click SAS inbound transport
Click Security > Secure administration, applications,
and infrastructure. Under RMI/IIOP security, click SAS outbound transport
For
the ORB SSL transports on the server level for WebSphere Application Server
Network Deployment, you can modify the SSL configuration repertoire aliases
in the following locations:
- Click Servers > Application servers > server_name. Under
Security, click Server security > CSIv2 inbound transport.
- Click Servers > Application servers > server_name. Under
Security, click Server security > CSIv2 outbound transport.
Click Servers > Application servers > server_name.
Under Security, click Server security > SAS inbound transport.
Click Servers > Application servers > server_name.
Under Security, click Server security > SAS outbound transport.
For the 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 New and type sslConfig in the name field, and
its value in the Value field.
For
additional SOAP JMX administrative transports for WebSphere Application Server
Network Deployment, you can modify the SSL configuration repertoire aliases
in the following locations:
- Click System administration > Deployment manager. Under Additional
properties, click 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.
- Click System administration > Node agents > node_agent_name.
Under Additional properties, 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 New and type sslConfig in the name
field, and its value in the Value field.
For the Lightweight Directory Access Protocol (LDAP) SSL transport,
you can modify the SSL configuration repertoire aliases by clicking Security
> Secure administration, applications, and infrastructure. Under User
account repository, click the Available realm definitions drop-down
list, and select Standalone LDAP registry.
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.
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.
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.
Servers > Application servers > server_name.
Under Security, click Server security > z/SAS authentication. Select
the appropriate SSL configuration from the SSL settings menu.
- 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.
- 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 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.
- 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.