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 v7. 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?
- 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 WebSphere Application Server
- Support information for Kerberos authentication
- Set up Kerberos as the authentication mechanism for WebSphere Application Server
- Set up Kerberos as the authentication mechanism for the pure Java client
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 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 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 WAS and participate
in SSO by using SPNEGO web authentication. Support for SPNEGO as the web authentication service is new to this release of WAS.
Read about Single sign-on for HTTP requests using SPNEGO web authentication for more information.
- WAS can support both Kerberos and 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
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
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
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 WebSphere Application Servers 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 the 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 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
In the previous figure, the following events occur:
- The client uses the Kerberos credential cache if it exists.
- The client requests a cross realm ticket (TGS_REQ) for Realm
A from the Realm B KDC using the Kerberos credential cache.
- The client uses a cross realm ticket to request Kerberos service ticket for server1 (TGS_REQ) from the Realm
A KDC.
- The Kerberos token returned from the KDC (TGS_REP ) is added to the CSIv2 message authentication token and sent to server1 for authentication.
- 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.
- Optionally, a custom JAAS Login Module might be needed if the KDC and WebSphere Application Server do not use the same user registry.
- The user is validated with the user registry for WebSphere Application Server.
- 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
In the previous figure, the following events occur:
- The client obtains the Kerberos granting ticket (TGT) from the KDC.
- The client obtains a Kerberos service ticket for server1 (TGS_REQ)
using the TGT.
- The Kerberos token returned from the KDC (TGS_REP ) is added to the CSIv2 message authentication token and sent to server1 for authentication.
- 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.
- Optionally, a custom JAAS Login Module might be needed if the KDC and WebSphere Application Server do not use the same user registry.
- The user is validated with the user registry for WebSphere Application Server.
- The results are returned to the client.
The following figure shows server-to-server communications:
Figure 5. 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. In the previous figure, the following events occur:
- WebSphere Application Server 1 invokes a method, foo(), on an EJB
running in WebSphere Application Server 2.
- Server1 obtains a Kerberos service ticket for Server2 (TGS_REQ)
using the Server1 TGT.
- Same as step 2.
- The Kerberos token returned from a KDC (TGS_REP) is added to the CSIv2 message authentication token and sent to Server2 for authentication.
- 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.
- 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, we can specify the realm name during the login process.gotcha
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 Configure 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 the 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.
(zos) The following security custom property should be set to true: com.ibm.websphere.security.krb.longLivedTicket.
- 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.
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 WAS, 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
- z/OS
- We 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 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 WAS 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.
- The preferred authentication mechanism for flexible management activities is the RSA authentication mechanism (by default).
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
Set up Kerberos as the authentication mechanism for WebSphere Application Server
We must perform the steps in order as listed in Set up Kerberos as the authentication mechanism for WebSphere Application Server 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 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.
Related tasks
Kerberos: The Network Authentication Protocol