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.
New feature: Security support for Kerberos as the
authentication mechanism has been added for this release of
WebSphere® Application Server. Kerberos is a
mature, flexible, open, and very secure network authentication protocol.
Kerberos includes authentication, mutual authentication, message
integrity and confidentiality and delegation features. You 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
WebSphere Application Server.
newfeat
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 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:
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 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:
Figure 2. Kerberos
authentication in a cross or trusted Kerberos realm environment

When theWebSphere 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 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 figure
above, 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
figure above, 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 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:
- 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.
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, you
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:
Note: 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.
![[Fix Pack 5 or later]](../../ngfp5.gif)
For this release of
WebSphere Application Server, 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
- 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 SPNEGO Web authentication with a browser client
The
following scenarios are supported:
- Cross-forest trusts
- Domain trust within the same forest
- Kerberos realm trust
The following scenarios are not supported:
- Forest external trusts
- Domain external trusts
Support
information for SPNEGO Web authentication with a Java client using the HTTP protocol
The
following scenarios are supported:
- Domain trust within the same forest
- External domain trust directly between domains within different
forests.
- Kerberos realm trust
The following scenarios are not supported:
- Cross-forest trust
- Forest external trust
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
Setting up Kerberos as the authentication
mechanism for WebSphere Application Server
You
must perform the following steps in order to set up Kerberos as the
authentication mechanism for
WebSphere Application Server.
Note: 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.
- Ensure that the KDC is configured.
See your Kerberos Administrator
and User's guide for more information.
To configure a KDC on z/OS,
you must activate the APPL class in RACF
®.
This action has the effect of enabling the APPL class profile defined
for WebSphere and might
restrict the ability of authenticated users to access applications
running on WebSphere.
If your security configuration is using an SAF profile prefix, the
profile name is the SAF profile prefix. Otherwise, the profile name
is CBS390. To control whether the APPL profile is checked for WebSphere authorization, you
can configure the checkbox labeled "Use APPL profile to restrict access
to the server" on the SAF authorization panel in the administrative
console. This setting can be configured at a WebSphere security domain level.
Avoid trouble: When configuring the
envar file for a z/OS KDC,
order the encryption types from most secure to least secure for the
SKDC_TKT_ENCTYPES environment variable. The z/OS KDC prefers to use the encryption types
that are first in the list, from left to right.
gotcha
- 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 Java virtual
machine (JVM). In this release of WebSphere Application Server, this configuration
file should be placed in the config/cells/<cell_name> directory
so that all application servers can access this file. If you do not
have a Kerberos configuration file, use a wsadmin command to
create one.
Read about Creating a Kerberos configuration file for more information.
- Set up Kerberos as the authentication mechanism for WebSphere Application Server on the server
side by using the administrative console.
Read about Configuring Kerberos as the authentication mechanism using the administrative console for more information.
For
information about how to set up Kerberos as the authentication mechanism
for WebSphere Application Server on the
server side by using wsadmin commands, read about Kerberos authentication commands.