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.
- 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
- Setting up Kerberos as the authentication mechanism for WebSphere Application Server
- Setting up Kerberos as the authentication mechanism for the pure Java client
Setting up Kerberos as the bind authentication mechanism for LDAP
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:
![WebSphere Application Server supports Kerberos authentication in a single Kerberos realm environment](images/Kerberos1.gif)
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:
![WebSphere Application Server also supports Kerberos authentication in a cross or trusted Kerberos realm environment](images/Kerberos2.gif)
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 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 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 .
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:
![Using a Kerberos credential cache to authenticate to WebSphere Application Server with a Kerberos token in a trusted Kerberos realm](images/JavaClient2.gif)
- 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:
![Using a Kerberos principal name and password to authenticate to WebSphere Application Server with a Kerberos token.](images/JavaClient3.gif)
- 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:
![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.](images/Kerberos3.gif)
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:
- WebSphere Application Server 1 invokes a method, foo(), on an Enterprise JavaBeans (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.
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.
- 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.
The following security custom property should be set to true: com.ibm.websphere.security.krb.longLivedTicket.
- 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.
- 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
- External domain trusts that are not on the same forests
- Domain trust within the same forest
- Kerberos realm trust
- Cross-forest trust
- Forest external trusts
Setting up Kerberos as the authentication mechanism for WebSphere Application Server
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.
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.