Selecting an authentication mechanism

An authentication mechanism defines rules about security information, such as whether a credential is forwardable to another Java™ process, and the format of how security information is stored in both credentials and tokens. You can select and configure an authentication mechanism by using the administrative console.

About this task

Authentication is the process of establishing whether a client is who or what it claims to be in a particular context. A client can be either an user, a machine, or an application. An authentication mechanism in WebSphere® Application Server typically collaborates closely with a user registry. The user registry is the user and groups account repository that the authentication mechanism consults with when performing authentication. The authentication mechanism is responsible for creating a credential, which is an internal product representation of a successfully authenticated client user. Not all credentials are created equally. The abilities of the credential are determined by the configured authentication mechanism.

WebSphere Application Server provides three authentication mechanisms: Lightweight Third Party Authentication (LTPA), Kerberos, and RSA token authentication mechanism.

Security support for Kerberos as the authentication mechanism has been added for this release of WebSphere Application Server. Kerberos (KRB5) is a mature, flexible, open, and very secure network authentication protocol. Kerberos includes authentication, mutual authentication, message integrity, and confidentiality and delegation features. KRB5 is used for Kerberos in the administrative console and in the sas.client.props, soap.client.props, and ipc.client.props files.

The RSA token authentication mechanism is new to this release of WebSphere Application Server. It aids the flexible management objective to preserve the base profiles configurations and isolate them from a security perspective. This mechanism permits the base profiles that are managed by an administrative agent to have different Lightweight Third-Party Authentication (LTPA) keys, different user registries, and different administrative users.

Note: Simple WebSphere Authentication Mechanism (SWAM) is deprecated in this release. SWAM does not provide authenticated communication between different servers.

Authentication is required for enterprise bean clients and web clients when they access protected resources. Enterprise bean clients, like a servlet or other enterprise beans or a pure client, send the authentication information to a web application server by using one of the following protocols:

  • Common Secure Interoperability Version 2 (CSIv2)
  • [AIX Solaris HP-UX Linux Windows][IBM i]Secure Authentication Service (SAS)
    Note: 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]z/OS® Secure Authentication Service (z/SAS)
    Note: z/SAS is supported only between Version 6.0.x and previous version servers that have been federated in a Version 6.1 cell.

Web clients use the HTTP or HTTPS protocol to send the authentication information.

The authentication information can be basic authentication (user ID and password), a credential token, or a client certificate. The web authentication is performed by the web authentication module.

You can configure web authentication for a web client by using the administrative console. Click Security > Global security. Under Authentication, expand Web and SIP security and click General settings. The following options exist for Web authentication:
Authenticate only when the URI is protected
Specifies that the web client can retrieve an authenticated identity only when it accesses a protected Uniform Resource Identifier (URI). WebSphere Application Server challenges the web client to provide authentication data when the web client accesses a URI that is protected by a J2EE role. This default option is also available in previous versions of WebSphere Application Server.
Use available authentication data when an unprotected URI is accessed
Specifies that the web client is authorized to call the getRemoteUser, isUserInRole, and getUserPrincipal methods; retrieves an authenticated identity from either a protected or an unprotected URI. Although the authentication data is not used when you access an unprotected URI, the authentication data is retained for future use. This option is available when you select the Authentication only when the URI is protected check box.
Authenticate when any URI is accessed
Specifies that the web client must provide authentication data regardless of whether the URI is protected.
Default to basic authentication when certificate authentication for the HTTPS client fails.
Specifies that WebSphere Application Server challenges the web client for a user ID and password when the required HTTPS client certificate authentication fails.

The enterprise bean authentication is performed by the Enterprise JavaBeans (EJB) authentication module.

[AIX Solaris HP-UX Linux Windows][IBM i]The EJB authentication module resides in the CSIv2 and SAS layer.

[z/OS]The EJB authentication module resides in the CSIv2 and z/SAS layer.

The authentication module is implemented by using the Java Authentication and Authorization Service (JAAS) login module. The web authenticator and the EJB authenticator pass the authentication data to the login module, which can use the following mechanisms to authenticate the data:

  • Kerberos
  • LTPA
  • RSA token
  • [z/OS]Simple WebSphere Authentication Mechanism (SWAM)
    Note: SWAM was deprecated in WebSphere Application Server Version 6.1 and will be removed in a future release.
The authentication module uses the registry that is configured on the system to perform the authentication. Four types of registries are supported:
  • Federated repositories
  • Local operating system
  • Stand-alone Lightweight Directory Access Protocol (LDAP) registry
  • Stand-alone custom registry

External registry implementation following the registry interface that is specified by IBM® can replace either the local operating system or the LDAP registry.

The login module creates a JAAS subject after authentication and stores the credential that is derived from the authentication data in the public credentials list of the subject. The credential is returned to the web authenticator or to the enterprise beans authenticator.

[AIX Solaris HP-UX Linux Windows][IBM i]The web authenticator and the enterprise beans authenticator store the received credentials in the Object Request Broker (ORB) current for the authorization service to use in performing further access control checks. If the credentials are forwardable, they are sent to other application servers.

[z/OS]The web authenticator and the enterprise beans authenticator store the received credentials for the authorization service to use in performing further access control checks.

You can configure authentication mechanisms in the administrative console by doing the following:

Procedure

  1. Click Security > Global security
  2. Under Authentication mechanisms and expiration, select an authentication mechanism to configure.