Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Authenticate users > Select an authentication mechanism


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.

Security support for Kerberos as the authentication mechanism was added for WAS 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. We 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 WAS.

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 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 WAS include the following:



Kerberos authentication in a single Kerberos realm environment

WAS 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

When the WAS 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 WAS 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

WAS 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

When the WAS 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 WAS 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 WAS, the new security multiple domains only support Kerberos at the cell level. All WASs 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 following figure shows a Java and administrative client that uses a Kerberos credential cache to authenticate to WAS with a Kerberos token in a trusted Kerberos realm:

Figure 3. Using a Kerberos credential cache to authenticate to WAS with a Kerberos token in a trusted Kerberos realm

In the figure above, 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 WAS do not use the same user registry.
  7. The user is validated with the user registry for WAS.
  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 WAS with a Kerberos token:

Figure 4. Using a Kerberos principal name and password to authenticate to WAS with a Kerberos token

In the figure above, 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 WAS do not use the same user registry.
  6. The user is validated with the user registry for WAS.
  7. The results are returned to the client.

The following figure shows server-to-server communications:

Figure 5. Server to server communicationsapplication 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 WAS 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 WAS uses the internal server ID instead of the server ID and password, server-to-server communication is done using an LTPA token. In the figure above, the following events occur:

  1. WAS 1 invokes a method, foo(), on an EJB running in WAS 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.
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.


Things to consider before setting up Kerberos as the authentication mechanism for WAS

WAS 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 client, WAS 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 WAS, be aware of the following:



Support information for Kerberos authentication

The following scenarios are supported:

The following scenarios are not supported:



Set up Kerberos as the authentication mechanism for WAS

We must perform the steps in order as listed in Set up Kerberos as the authentication mechanism for WAS to set up Kerberos as the authentication mechanism for WAS.

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.


Set 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 Configure a Java client for Kerberos authentication for more information.
Create a Kerberos service principal name and keytab file
Create a Kerberos configuration file
Configure Kerberos as the authentication mechanism
Configure a Java client for Kerberos authentication
Authenticate users
Configure CSIV2 inbound and outbound communication settings
Configure SPNEGO web authentication
Map of a client Kerberos principal name to the WebSphere user registry ID


Related


Kerberos authentication commands
SPNEGO web authentication configuration commands
Use the ktab command to manage the Kerberos keytab file
Kerberos: The Network Authentication Protocol

+

Search Tips   |   Advanced Search