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.

Note: Security support for Kerberos as the authentication mechanism was added for WebSphere® Application Server Version 7.0. Kerberos is a mature, flexible, open, and very secure network authentication protocol. Kerberos includes authentication, mutual authentication, message integrity and confidentiality and delegation features. You can enable Kerberos on the server side. Support is provided to enable the rich Java™ client to use the Kerberos token for authentication to the WebSphere Application Server.
The following sections describe Kerberos authentication in more detail:

What is Kerberos?

Kerberos has withstood the test of time and is now at version 5.0. Kerberos enjoys wide spread platform support (for example, for Windows, Linux®, Solaris, AIX®, and z/OS®) partly because the Kerberos source code is freely downloadable from the Massachusetts Institute of Technology (MIT) where it was originally created.

Kerberos is composed of three parts: a client, a server, and a trusted third party known as the Kerberos Key Distribution Center (KDC). The KDC provides authentication and ticket granting services.

The KDC maintains a database or repository of user accounts for all of the security principals in its realm. Many Kerberos distributions use file-based repositories for the Kerberos principal and policy DB and others use Lightweight Directory Access Protocol (LDAP) as the repository.

Kerberos does not support any notion of groups (that is, iKeys groups or groups of users or principals). The KDC maintains a long-term key for each principal in its accounts database. This long-term key is derived from the password of the principal. Only the KDC and the user that the principal represents should know what the long-term key or password is.

The benefits of having Kerberos as an authentication mechanism

The benefits of having Kerberos as the authentication mechanism for WebSphere Application Server include the following:

  • The Kerberos protocol is a standard. This 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.
  • When using Kerberos authentication, the user clear text password never leaves the user machine. The user authenticates and obtains a Kerberos ticket granting ticket (TGT) from a KDC by using a one-way hash value of the user password. The user also obtains a Kerberos service ticket from the KDC by using the TGT. The Kerberos service ticket that represents the client identity is sent to WebSphere Application Server for authentication.
  • A Java client can participate in Kerberos SSO using the Kerberos credential cache to authenticate to WebSphere Application Server.
  • J2EE, web service, .NET and web browser clients that use the HTTP protocol can use the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) token to authenticate to the WebSphere Application Server and participate in SSO by using SPNEGO web authentication. Support for SPNEGO as the web authentication service is new to this release of WebSphere Application Server.

    Read about SPNEGO single sign-on for more information.

  • WebSphere Application Server can support both Kerberos and Lightweight Third-Party Authentication (LTPA) authentication mechanisms at the same time.
  • Server-to-server communication using Kerberos authentication is provided.

Kerberos authentication in a single Kerberos realm environment

WebSphere Application Server supports Kerberos authentication in a single Kerberos realm environment as shown in the following figure:

Figure 1. Kerberos authentication in a single Kerberos realm environment
WebSphere Application Server supports Kerberos authentication in a single Kerberos realm environment

When the WebSphere Application Server receives a Kerberos or SPNEGO token for authentication, it uses the Kerberos service principal (SPN) to establish a security context with a requestor. If a security context is established, the WebSphere Kerberos login module extracts a client GSS delegation credential, creates a Kerberos authentication token base on the Kerberos credential, and places them in the client subject with other tokens.

If the server must use a downstream server or back-end resources, it uses the client GSS delegation credential. If a downstream server does not support Kerberos authentication, the server uses the LTPA token instead of the Kerberos token. If a client does not include a GSS delegation credential in the request, the server uses the LTPA token for the downstream server . The Kerberos authentication token and principal are propagated to the downstream server as part of the security attributes propagation feature.

If the WebSphere Application Server and the KDC do not use the same user registry, then a JAAS custom login module might be required to map the Kerberos principal name to the WebSphere user name.

Kerberos authentication in a cross or trusted Kerberos realm environment

WebSphere Application Server also supports Kerberos authentication in a cross or trusted Kerberos realm environment as shown in the following figure:

Figure 2. Kerberos authentication in a cross or trusted Kerberos realm environment
WebSphere Application Server also supports Kerberos authentication in a cross or trusted Kerberos realm environment

When the WebSphere Application Server receives a Kerberos or SPNEGO token for authentication, it uses the Kerberos service principal (SPN) to establish a security context with a requestor. If a security context is established, the WebSphere Kerberos login module always extracts a client GSS delegation credential and Kerberos ticket and places them in the client subject with other tokens.

If the server must use a downstream server or backend resources, it uses the client GSS delegation credential. If a downstream server does not support Kerberos authentication, the server uses the LTPA token instead of the Kerberos token. If a client does not include a GSS delegation credential in the request, the server uses the LTPA token for the downstream server . The Kerberos authentication token and principal are propagated to the downstream server as part of the security attributes propagation feature.

If the WebSphere Application Server and the KDC do not use the same user registry, then a JAAS custom login module might be required to map the Kerberos principal name to the WebSphere user name.

In this release of WebSphere Application Server, the new security multiple domains only support Kerberos at the cell level. All WebSphere Application Server must be used by the same Kerberos realm. However, the clients and or backend resources (such as DB2, .NET server, and others) that support Kerberos authentication can have their own Kerberos realm. Only peer-to-peer and transitive trust cross-realm authentication are supported. The following steps must be performed for trusted Kerberos realms:

  • The Kerberos trusted realm setup must be done on each of the Kerberos KDCs. See your Kerberos Administrator and User's guide for more information about how to set up a Kerberos trusted realm.
  • The Kerberos configuration file might need to list the trusted realm.
  • Add Kerberos trusted realms in the administrative console by clicking Global security > CSIv2 outbound communications > Trusted authentication realms - outbound.

The following figure shows a Java and administrative client that uses a Kerberos credential cache to authenticate to WebSphere Application Server with a Kerberos token in a trusted Kerberos realm:

Figure 3. Using a Kerberos credential cache to authenticate to WebSphere Application Server with a Kerberos token in a trusted Kerberos realm
Using a Kerberos credential cache to authenticate to WebSphere Application Server with a Kerberos token in a trusted Kerberos realm
In the previous figure, the following events occur:
  1. The client uses the Kerberos credential cache if it exists.
  2. The client requests a cross realm ticket (TGS_REQ) for Realm A from the Realm B KDC using the Kerberos credential cache.
  3. The client uses a cross realm ticket to request Kerberos service ticket for server1 (TGS_REQ) from the Realm A KDC.
  4. The Kerberos token returned from the KDC (TGS_REP ) is added to the CSIv2 message authentication token and sent to server1 for authentication.
  5. The server calls Krb5LoginModuleWrapper to establish security context with the client using the server Kerberos Service Principal Name (SPN) and keys from the krb5.keytab file. If the server successfully establishes a security context with the client, it always extracts the client GSS delegation credential and tickets and places them in the client subject.
  6. Optionally, a custom JAAS Login Module might be needed if the KDC and WebSphere Application Server do not use the same user registry.
  7. The user is validated with the user registry for WebSphere Application Server.
  8. The results (success or failure) are returned to the client.

The following figure shows a Java and administrative client that uses a Kerberos principal name and password to authenticate to WebSphere Application Server with a Kerberos token:

Figure 4. Using a Kerberos principal name and password to authenticate to WebSphere Application Server with a Kerberos token
Using a Kerberos principal name and password to authenticate to WebSphere Application Server with a Kerberos token.
In the previous figure, the following events occur:
  1. The client obtains the Kerberos granting ticket (TGT) from the KDC.
  2. The client obtains a Kerberos service ticket for server1 (TGS_REQ) using the TGT.
  3. The Kerberos token returned from the KDC (TGS_REP ) is added to the CSIv2 message authentication token and sent to server1 for authentication.
  4. The server calls Krb5LoginModuleWrapper to establish security context with the client using the server Kerberos Service Principal Name (SPN) and keys from the krb5.keytab file. If the server successfully establishes a security context with the client, it always extracts the client GSS delegation credential and tickets and places them in the client subject.
  5. Optionally, a custom JAAS Login Module might be needed if the KDC and WebSphere Application Server do not use the same user registry.
  6. The user is validated with the user registry for WebSphere Application Server.
  7. The results are returned to the client.

The following figure shows server-to-server communications:

Figure 5. Server to server communications
When a WebSphere application server starts up, it uses the server ID and password to login to the KDC and then obtains the TGT. It then uses the TGT to request a service ticket to communicate with another server. If a WebSphere application server uses the internal server ID instead of the server ID and password, server-to-server communication is done using an LTPA token.

When a WebSphere Application Server starts up, it uses the server ID and password to login to the KDC and then obtains the TGT. It then uses the TGT to request a service ticket to communicate with another server. If a WebSphere Application Server uses the internal server ID instead of the server ID and password, server-to-server communication is done using an LTPA token. In the previous figure, the following events occur:

  1. WebSphere Application Server 1 invokes a method, foo(), on an Enterprise JavaBeans (EJB) running in WebSphere Application Server 2.
  2. Server1 obtains a Kerberos service ticket for Server2 (TGS_REQ) using the Server1 TGT.
  3. Same as step 2.
  4. The Kerberos token returned from a KDC (TGS_REP) is added to the CSIv2 message authentication token and sent to Server2 for authentication.
  5. Server2 calls the acceptSecContext() method to establish security context with server1 using the server2 Kerberos Service Principal Name (SPN) and keys from the krb5.keytab file. If server2 successfully establishes a security context with server1, it always extracts the server1 GSS delegation credential and tickets and places them in the subject.
  6. The server id is validated with the WebSphere user registry.
Avoid trouble: If a Java client application and the application server exist on the same machine and they use different Kerberos realm names, the run time uses the default realm name from the Kerberos configuration file. Alternatively, you can specify the realm name during the login process.
Avoid trouble: Kerberos and LTPA authentication can be configured in multiple KDC environments. Basic authentication can consist of a password and a short name without the Kerberos realm name. For this basic authentication, a combination of the domain_realm element and the default_realm element determines which KDC the Kerberos client uses to authenticate the request. Users who do not belong to the determined KDC must log in with a fully qualified Kerberos principal name, for example, Bob@myKerberosRealm.

Things to consider before setting up Kerberos as the authentication mechanism for WebSphere Application Server

WebSphere Application Server now supports SPNEGO tokens in the HTTP header, Kerberos tokens, LTPA tokens and BasicAuth (GSSUP) for authentication.

To provide end-to-end Kerberos and end-to-end SPNEGO to Kerberos solutions, be aware of the following:
  • The Enabled delegation of Kerberos credentials option must be selected. Read about Configuring Kerberos as the authentication mechanism using the administrative console for more information about this option.
  • A client must obtain a ticket-granting ticket (TGT) with forwardable, address-less and renewable flags so that a target server can extract a client delegation Kerberos credential and use it for going to the downstream server.
  • A client TGT that has an address can not be used for a downstream server, Data replication service (DRS) cache and cluster environments.
  • See your Kerberos KDC platforms to make sure that it allows for client delegation Kerberos.
  • For a long running application, a client should request a TGT with a renewable flag so that a target server can renew the delegation Kerberos.
  • For a long-running application, ensure that the Kerberos ticket is valid for a period of time that is at least as long as the application runs. For example, if the application processes a transaction that takes 5 minutes, the Kerberos ticket must be valid for at least 5 minutes.
  • Kerberos authentication and SPNEGO web authentication are both supported for Active Directory cross domain trusts within the same forest.
  • In order for an administrative agent to use the Kerberos authentication mechanism, it must exchange an LTPA key with an administrative subsystem profile.
  • If you plan to use the client delegation Kerberos credential for downstream authentication, make sure the client can request a service ticket that is greater than 10 minutes. If the client delegation Kerberos credential lifetime is less than 10 minutes, then the server attempts to renew it.
Note: The client, WebSphere Application Server and KDC machines must keep the clock synchronized. The best practice is to use a time server to keep all of the systems synchronized.
For this release of WebSphere Application Server, be aware of the following:
  • Complete end-to-end Kerberos support with Tivoli® Access Manager is available using the following KDCs:
    • z/OS
    • Microsoft (single or multi-realm)
    • AIX
    • Linux
  • You can now configure and enable Kerberos cross realms for WebSphere Application Server and the thin client.
  • WebSphere Application Server administrative function with Kerberos is limited by the following:
    • The preferred authentication mechanism for flexible management activities is the Rivest Shamir Adleman (RSA) authentication mechanism (by default).
    • Job Manager configured with Kerberos as the administrative authentication does not support Cross-Kerberos realms. They must be in the same Kerberos realm as registered nodes, or have the administrative authentication set to RSA
    • While Kerberos authentication is supported for administrative clients (wsadmin or Java clients) you should use the same KDC realm as the WebSphere Application Server it administers. Otherwise, a user id and password are recommended.
    • Mixed cell Kerberos and LTPA configuration is not supported when some of the nodes are WebSphere Application Server Release 6.x nodes or earlier.

Support information for Kerberos authentication

The following scenarios are supported:
  • External domain trusts that are not on the same forests
  • Domain trust within the same forest
  • Kerberos realm trust
The following scenarios are not supported:
  • Cross-forest trust
  • Forest external trusts

Setting up Kerberos as the authentication mechanism for WebSphere Application Server

You must perform the steps in order as listed in Setting up Kerberos as the authentication mechanism for WebSphere Application Server to set up Kerberos as the authentication mechanism for WebSphere Application Server.
Note: Kerberos authentication mechanism on the server side must be done by the system administrator and on the Java client side by users. The Kerberos keytab file must to be protected.

Setting up Kerberos as the authentication mechanism for the pure Java client

End users can optionally set up Kerberos authentication mechanism for the pure Java client. Read about Configuring a Java client for Kerberos authentication for more information.

[9.0.5.7 or later]

Setting up Kerberos as the bind authentication mechanism for LDAP

You can set up Kerberos as the bind authentication mechanism to bind to the LDAP server and do user and group searches. This bind authentication mechanism is an alternative to the simple bind authentication mechanism, which uses a bind distinguished name and a bind password.

To configure Kerberos as the bind authentication mechanism for LDAP servers in federated repositories, complete the steps in the topic about configuring LDAP in a federated repository configuration.

To configure Kerberos as the bind authentication mechanism for a stand-alone LDAP server, complete the steps in the topic about configuring LDAP user registries.