Kerberos (KRB5) authentication mechanism support for security

Overview

The Kerberos authentication mechanism...

• enables interoperability with other applications (such as .NET, DB2 and others)
• enables single sign
• preserves the original requester identity

New feature: Security support for Kerberos as the authentication mechanism has been added for WAS v7.

Kerberos includes...

• authentication
• mutual authentication
• message integrity and confidentiality
• delegation features

Kerberos tokens for authentication to the WAS is supported by...

• application server
• rich Java client

Kerberos tokens for authentication to the appserver is not supported by...

• thin client
• administrative thin client
• application client

These thin clients must instead use BasicAuth/GSSUP for authentication to the appserver.

The following sections describe Kerberos authentication in more detail:

• What is Kerberos?
• The benefits of having Kerberos as an authentication mechanism
• Kerberos authentication in a single Kerberos realm environment
• Kerberos authentication in a cross or trusted Kerberos realm environment
• Things to consider before setting up Kerberos as the authentication mechanism for WAS
• Set up Kerberos as the authentication mechanism for WAS
• Set up Kerberos as the authentication mechanism for the pure Java client

 

What is Kerberos?

Kerberos V5.0 runs on Windows, Linux, Solaris, AIX, and z/OS and is freely downloadable from the MIT.

Kerberos is composed of three parts:

• client
• server
• Kerberos Key Distribution Center (KDC)

The KDC...

• Provides authentication and ticket granting services
• Maintains a database of security principals
• Maintains a database of security policies

Both file-based and LDAP can be used, depending on the Kerberos flavor you are using.

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:

• The Kerberos protocol is a standard.

  This enables interoperability with other applications (such as .NET, DB2 and others) that support Kerberos authentication. It provides 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 WAS 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 SPNEGO token to authenticate to the WAS and participate in SSO by using SPNEGO Web authentication.

  Support for SPNEGO as the Web authentication service is new to WAS v7.

• WAS 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

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

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 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 WAS user registry.

8. The results (success or failure) are returned to the client.

When the WAS receives a Kerberos or SPNEGO token for authentication, it uses the Kerberos 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.

For multiple domains, WAS v7 only supports Kerberos at the cell level, with all WAS resources in the same Kerberos realm. However, the clients and or backend resources, such as DB2, .NET server, and others, can have their own Kerberos realm.

Only peer-to-peer and transitive trust cross-realm authentication are supported.

Enable trusted Kerberos realms

1. Kerberos trusted realm setup must be done on each of the Kerberos KDCs.
2. The Kerberos configuration file might need to list the trusted realm.

3. Add Kerberos trusted realms in the admin console...

   Global security | CSIv2 outbound communications | Trusted authentication realms - outbound

For a Kerberos principle name and password to authenticate with a Kerberos token...

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 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 WAS user registry.

7. The results are returned to the client.

The following figure shows 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. In the figure above, the following events occur:

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

 

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

For authentication, WAS supports...

• SPNEGO tokens in the HTTP header
• Kerberos tokens
• LTPA tokens
• BasicAuth (GSSUP)

To provide end-to-end Kerberos and end-to-end SPNEGO to Kerberos solutions...

• The Enabled delegation of Kerberos credentials option must be selected.

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

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

• Kerberos authentication and SPNEGO Web authentication are both supported for Active Directory cross domain trusts within the same forest. SPNEGO Web authentication is also supported for Active Directory cross forest trusts. However, Kerberos authentication is not supported for Active Directory cross forest trusts.

• In order for an administrative agent to use the Kerberos authentication mechanism, it must exchange an LTPA key with an admin subsystem profile.

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.

 

Set up Kerberos as the authentication mechanism for WAS

To set up Kerberos as the authentication mechanism for WAS.

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

2. Verify the KDC is configured.

3. 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 JVM, which should be placed in...

   config/cells/cellname

   ...so that all appservers can access this file. If we do not have a Kerberos configuration file, use a wsadmin command to create one.

4. 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 that are allowed by the KDC. However, for SPNEGO Web authentication, the service name must be HTTP. An example of a WebSphere Application Sever server ID is...

   WAS/myhost.mpls.setgetweb.com.

   Each host must have a server ID unique to the hostname. All processes on the same node share the same host-based service ID.

   A Kerberos administrator creates a Kerberos SPN for each node in the WebSphere cell. For example, for a cell with 3 nodes, such as...

   • server1.mpls.setgetweb.com
   • server2.mpls.setgetweb.com
   • server3.mpls.setgetweb.com

   ...the Kerberos administrator must create the following Kerberos service principals:

   • WAS/server1.mpls.setgetweb.com
   • WAS/server2.mpls.setgetweb.com
   • WAS/server3.mpls.setgetweb.com

   The Kerberos keytab file (krb5.keytab) contains all of the SPNs for the node and must be protected. This file can be placed in...

   config/cells/cellname;

5. Set up Kerberos as the authentication mechanism for WAS on the server side by using the admin console.

   See also: Kerberos authentication commands.

6. A custom JAAS Login Module might be needed if the KDC and WAS do not use the same user registry.

 

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

End users can set up Kerberos authentication mechanism for the pure Java client.

---

 

Related tasks

Create a Kerberos service principal and keytab file
Set a Java client for Kerberos authentication
Authenticate users
Create a Kerberos configuration file
Set CSIV2 inbound and outbound communication settings
SPNEGO Web authentication
Set Kerberos as the authentication mechanism

 

Related

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