+

Search Tips   |   Advanced Search

Kerberos (KRB5) authentication mechanism support for security

The Kerberos v5 authentication mechanism enables interoperability with applications such as .NET, DB2 and others. Kerberos provides single sign on (SSO) end-to-end interoperable solutions and preserves the original requester identity. 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 WebSphere Application Server.

Kerberos is composed of three parts:

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 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 using a one-way hash value of the user password. The user also obtains a Kerberos service ticket from the KDC using the TGT. The Kerberos service ticket that represents the client identity is sent to WAS for authentication.

A Java client can participate in Kerberos SSO using the Kerberos credential cache to authenticate to WAS.

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 WAS and participate in SSO using SPNEGO web authentication. Support for SPNEGO as the web authentication service is new to this release of WAS.

WAS can support both Kerberos and LTPA authentication mechanisms at the same time.

Server-to-server communication using Kerberos authentication is provided.

See also: Video: How does Kerberos work?


Kerberos authentication in a single Kerberos realm environment

WAS supports 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...

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 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 multiple security domains only support Kerberos at the cell level. All WAS 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:

  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 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:

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 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:

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.

  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 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, we can specify the realm name during the login process.

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 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 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.