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.
![[iSeries]](../../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.