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.
After you understand the security
components, you can proceed to configure security in WebSphere Application Server.
Procedure
- Start the WebSphere Application Server administrative
console.
If
security is disabled, you are prompted for a user ID. Log in with
any user ID. However, if security is 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.
The
Primary administrative user name does not run WebSphere Application Server processes. Rather,
the process ID runs the WebSphere Application Server processes.
In the default configuration, WebSphere Application Server processes run
under the QEJBSVR system-provided user profile.
- 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.
- 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.5 and will be removed
in a future release. SWAM credentials are not forwardable to other machines
and for that reason do not expire.
- 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 Security 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 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 SAS, see the article, Configuring Common Secure Interoperability Version 2 (CSIV2) inbound and outbound communication settings.
Attention: IBM® no
longer ships or supports the Secure Authentication Service (SAS) IIOP
security protocol. It is recommended that you use the Common Secure
Interoperability version 2 (CSIv2) protocol.
- Click Security > Global security to configure
the rest of the security settings and enable security. For
information about these settings, see Global security settings.
- 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.
- Start the WebSphere Application Server administrative
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.