Authentication mechanisms
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.
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 WAS 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 creates 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.
LTPA is the only authentication mechanism available in a ND environment.
Authentication process
The figure demonstrates the authentication process. 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 federated in a V6.1 cell.
Web clients use the HTTP or HTTPS protocol to send the authentication information, as shown in the previous figure.
The authentication information can be basic authentication (user ID and password), a credential token (in the case of ), 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 console. Click...
Security | Secure administration and applications | Authentication | Web security | 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 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
- Specifies that the Web client is authorized to call the methods...
- getRemoteUser
- isUserInRole
- getUserPrincipal
...and retrieve 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 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 (2), which can use the following mechanisms to authenticate the data:
The authentication module uses the registry that is configured on the system to perform the authentication (4). Four types of registries are supported:
- Federated repositories
- Local operating system
- Standalone LDAP registry
- Standalone 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 (5).
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 appservers.
Sub-topics
Portlet URL security
LTPA
Trust associations
Single sign-on
Security attribute propagation
UserRegistry interface methods