WAS v8.5 > Secure applications > Authenticate users

Select 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. We can select and configure an authentication mechanism using the dmgr console. 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 end 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 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.

WAS provides three authentication mechanisms: LTPA (LTPA), Kerberos, and RSA token authentication mechanism.

Security support for Kerberos as the authentication mechanism has been added for this release of WAS. 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 dmgr 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 WAS. 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 managed by an administrative agent to have different Lightweight Third-Party Authentication (LTPA) keys, different user registries, and different administrative users.

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 using one of the following protocols:

• Common Secure Interoperability v2 (CSIv2)
• Secure Authentication Service (SAS)

  SAS is supported only between v6.0.x and previous version servers that have been federated in a v6.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.

We can configure web authentication for a web client using the dmgr 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

The web client can retrieve an authenticated identity only when it accesses a protected Uniform Resource Identifier (URI). WAS 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 WAS.

Use available authentication data when an unprotected URI is accessed

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 we access an unprotected URI, the authentication data is retained for future use. This option is available when we select the Authentication only when the URI is protected check box.

Authenticate when any URI is accessed

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 WAS 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 EJB authentication module.

The EJB authentication module resides in the CSIv2 and SAS layer.

The authentication module is implemented using the 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
• Simple WebSphere Authentication Mechanism (SWAM)

  SWAM was deprecated in WAS v8.5 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
• Standalone LDAP registry
• Stand-alone custom registry

External registry implementation following the registry interface 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.

The web authenticator and the enterprise beans authenticator store the received credentials in the 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.

We can configure authentication mechanisms in the dmgr console by doing the following:

1. Click Security > Global security.
   

2. Under Authentication mechanisms and expiration, select an authentication mechanism to configure.

Subtopics

• LTPA
  LTPA is intended for distributed, multiple application server and machine environments. LTPA supports forwardable credentials and SSO. LTPA can support security in a distributed environment through cryptography. This support permits LTPA to encrypt, digitally sign, and securely transmit authentication-related data, and later decrypt and verify the signature.
• Configure LTPA and work with keys
  You must configure LTPA when we set up security for the first time. LTPA is the default authentication mechanism for WAS. After we have configured LTPA we can generate LTPA keys manually or automatically.
• Configure the LTPA mechanism
  You must configure LTPA or Kerberos when we set up security for the first time.
• Kerberos (KRB5) authentication mechanism support for security
  The Kerberos authentication mechanism enables interoperability with other applications (such as .NET, DB2 and others) that support Kerberos authentication. It provides single sign on (SSO) end-to-end interoperable solutions and preserves the original requester identity.
• Set up Kerberos as the authentication mechanism for WAS
  You must perform steps in this article in order to set up Kerberos as the authentication mechanism for WAS.
• RSA token authentication mechanism
  The Rivest Shamir Adleman (RSA) Authentication Mechanism is used to simplify the security environment for the Flexible Management Topology. It supports the ability to securely and easily register new servers to the Flexible Management topology. With the Flexible Management topology, we can submit and manage administrative jobs, locally or remotely, using a job manager that manages applications, performs product maintenance, modifies configurations, and controls the application server runtime. The RSA authentication mechanism is only used for server-to-server administrative authentication, such as admin connector and file transfer requests. The RSA authentication mechanism does not replace LTPA or Kerboros for use by applications.
• Configure the RSA token authentication mechanism
  Use dmgr console to configure the Rivest Shamir Adleman (RSA) token authentication mechanism. The RSA token authentication mechanism can only be used for administrative requests. As such, the authentication mechanism choices for administrative authentication are part of the Global Security panel of the dmgr console.
• Simple WebSphere authentication mechanism (deprecated)
  The Simple WebSphere authentication mechanism (SWAM) defines rules about security information and the format of how security information is stored in both credentials and tokens. SWAM is intended for simple, non-distributed, single application server runtime environments.
• Message layer authentication
  Defines the credential information and sends that information across the network so that a receiving server can interpret it.
• LTPA
  LTPA is intended for distributed, multiple application server and machine environments. LTPA supports forwardable credentials and SSO. LTPA can support security in a distributed environment through cryptography. This support permits LTPA to encrypt, digitally sign, and securely transmit authentication-related data, and later decrypt and verify the signature.
• Configure LTPA and work with keys
  You must configure Lightweight Third Party Authentication (LTPA) when we set up security for the first time. LTPA is the default authentication mechanism for WAS. After we have configured LTPA we can generate LTPA keys manually or automatically.
• Kerberos (KRB5) authentication mechanism support for security
  The Kerberos authentication mechanism enables interoperability with other applications (such as .NET, DB2 and others) that support Kerberos authentication. It provides single sign on (SSO) end-to-end interoperable solutions and preserves the original requester identity.
• Set up Kerberos as the authentication mechanism for WAS
  You must perform steps in this article in order to set up Kerberos as the authentication mechanism for WAS.
• RSA token authentication mechanism
  The Rivest Shamir Adleman (RSA) Authentication Mechanism is used to simplify the security environment for the Flexible Management Topology. It supports the ability to securely and easily register new servers to the Flexible Management topology. With the Flexible Management topology, we can submit and manage administrative jobs, locally or remotely, using a job manager that manages applications, performs product maintenance, modifies configurations, and controls the application server runtime. The RSA authentication mechanism is only used for server-to-server administrative authentication, such as admin connector and file transfer requests. The RSA authentication mechanism does not replace LTPA or Kerboros for use by applications.
• Configure the RSA token authentication mechanism
  Use dmgr console to configure the Rivest Shamir Adleman (RSA) token authentication mechanism. The RSA token authentication mechanism can only be used for administrative requests. As such, the authentication mechanism choices for administrative authentication are part of the Global Security panel of the dmgr console.
• Simple WebSphere authentication mechanism (deprecated)
  The Simple WebSphere authentication mechanism (SWAM) defines rules about security information and the format of how security information is stored in both credentials and tokens. SWAM is intended for simple, non-distributed, single application server runtime environments.
• Message layer authentication
  Defines the credential information and sends that information across the network so that a receiving server can interpret it.

Related

Configure Kerberos as the authentication mechanism
Configure a Java client for Kerberos authentication
Authenticate users

Reference:

Web authentication settings

+

Search Tips   |   Advanced Search