Set up Kerberos as the authentication mechanism for WAS
We must perform the steps to set up Kerberos as the authentication mechanism for WebSphere Application Server.
Kerberos authentication mechanism on the server side must be done by the system administrator and on the Java client side by end users. The Kerberos keytab file must to be protected.
We must first ensure that the KDC is configured. See your Kerberos Administrator and User's guide.
(ZOS) To configure a KDC on z/OS, we must activate the APPL class in RACF . This action has the effect of enabling the APPL class profile that is defined for WebSphere and might restrict the ability of authenticated users to access applications that run on WebSphere. If the security configuration is using an SAF profile prefix, the profile name is the SAF profile prefix. Otherwise, the profile name is CBS390. To control whether the APPL profile is checked for WebSphere authorization, we can configure the checkbox that is labeled "Use APPL profile to restrict access to the server" on the SAF authorization panel in the administrative console. This setting can be configured at a WebSphere security domain level.
When configuring the envar file for a z/OS KDC, order the encryption types from most secure to least secure for the SKDC_TKT_ENCTYPES environment variable. The z/OS KDC prefers to use the encryption types that are first in the list, from left to right.
We must perform the following steps to set up Kerberos as the authentication mechanism for WAS.
Tasks
- Create a Kerberos service principal name and keytab file
- Create a Kerberos service principal name and keytab file when using Microsoft Windows, iSeries, Linux, Solaris, Massachusetts Institute of Technology (MIT) and z/OS operating systems key distribution centers (KDCs). Kerberos prefers servers and services to have a host-based service ID. The format of this ID is <service name>/<fully qualified hostname>. The default service name is WAS. For Kerberos authentication, the service name can be any strings allowed by the KDC. However, for SPNEGO web authentication, the service name must be HTTP. An example of a WAS ID is WAS/myhost.austin.ibm.com.
Each host must have a server ID unique to the host name. All processes on the same node share the same host-based service ID.
A Kerberos administrator creates a Kerberos service principal name (SPN) for each node in the WebSphere cell. For example, for a cell with three nodes (such as server1.austin.ibm.com, server2.austin.ibm.com and server3.austin.ibm.com), the Kerberos administrator must create the following Kerberos service principals: WAS/server1.austin.ibm.com, WAS/server2.austin.ibm.com, and WAS/server3.austin.ibm.com.
The Kerberos keytab filekrb5.keytab contains all of the SPNs for the node and must be protected. This file can be placed in the config/cells/cell directory.
Read the Creating a Kerberos principal and keytab article for more information.
- Create a Kerberos configuration file
- The IBM implementation of the Java Generic Security Service (JGSS) and KRB5 require a Kerberos configuration file krb5.conf or krb5.ini on each node or Java virtual machine (JVM). In this release of WAS, this configuration file should be placed in the config/cells/cell directory so that all application servers can access this file. If we do not have a Kerberos configuration file, use a wsadmin command to create one. Read the Creating a Kerberos configuration article for more information.
- Configure Kerberos as the authentication mechanism for WAS using the administrative console
- Use the administrative console to configure Kerberos as the authentication mechanism for the application server. When we have entered and applied the needed information to the configuration, the Kerberos service principal name is formed as <service name>/<fully qualified hostname>@KerberosRealm, and is used to verify incoming Kerberos token requests. Read the Configuring Kerberos as the authentication mechanism using the administrative console article for more information.
- Map a client Kerberos principal name to the WebSphere user registry ID
- We can map the Kerberos client principal name to the WebSphere user registry ID for both Simple and Protected GSS-API Negotiation (SPNEGO) web authentication and Kerberos authentication. Read the Mapping of a client Kerberos principal name to the WebSphere user registry ID article for more information.
(ZOS) We can optionally map a Kerberos principal to a System Authorization Facility (SAF) identity on z/OS.
(ZOS) If we choose the Use the KERB segment of an SAF user profile radio button on the Kerberos panel of the WAS administrative console, we must have your Local OS users that are mapped to a specific Kerberos principal. Read Mapping a Kerberos principal to a System Authorization Facility (SAF) identity on z/OS for more information.
- Set up Kerberos as the authentication mechanism for the pure Java client (optional)
- A Java client can authenticate with the WAS using a Kerberos principal name and password or with the Kerberos credential cache (krb5Ccache). Read the Configuring a Java client for Kerberos authentication article for more information.
Create a Kerberos service principal name and keytab file Create a Kerberos configuration file Configure Kerberos as the authentication mechanism Mapping of a client Kerberos principal name to the WebSphere user registry ID Configure a Java client for Kerberos authentication (ZOS) Mapping a Kerberos principal to a System Authorization Facility (SAF) identity on z/OS Authenticating users Configure CSIv2 inbound and outbound communication settings Enable and configure SPNEGO web authentication Kerberos authentication commands SPNEGO web authentication configuration commands Use the ktab command to manage the Kerberos keytab file Kerberos: The Network Authentication Protocol