The Kerberos authentication mechanism may be used when
both WebSphere® Application Server and the
DB2 server are configured for Kerberos authentication. Kerberos authentication
can provide single sign on (SSO) end-to-end interoperable solutions
and preserves the original requester identity.
Before you begin
In the application server, you can configure a DB2 data source,
the application server, and your application so that the DB2 data
source and the application server interoperate using delegated Kerberos
credentials in an end-to-end manner for database access by the application.
In order to take advantage of DB2 Kerberos authentication using delegated
credentials from the application server, referred to in this topic
as
option 1, you need to configure both DB2 and the application
server to use Kerberos as the authentication mechanism. See the topic,
“Kerberos (KRB5) authentication mechanism support for security” to
learn how to set up Kerberos as the authentication mechanism in this
version of the application server.
The XARecovery and TestConnection
facilities of the application server are not able to supply delegated
Kerberos credentials to the data source. There might also be situations
where the application server security component is unable to supply
delegated Kerberos credentials for a given connection request. To
account for these cases you can configure a DB2 connection using Kerberos
authentication referred to in this topic as option 2. For
this option, a user ID and password must be supplied to the JDBC driver
that the driver uses to obtain its own Kerberos credentials. To use
this option, you must configure a J2C authentication data alias on
the application server which defines the user ID and password that
the DB2 JDBC driver will use to request a Kerberos Ticket Granting
Ticket (TGT). The TGT is used for Kerberos authentication to a DB2
server. To the application server, this looks much like the typical
user ID and password authentication.
You must use a DB2 JDBC
driver that supports Kerberos authentication and is operating in type
4 mode. The supported JDBC drivers are:
- IBM Data Server Driver for JDBC and SQLJ (identified in the application
server as DB2 using IBM JCC Driver)
- IBM DB2 JDBC Universal Driver Architecture (identified in the
application server as DB2 Universal JDBC Driver Provider)
About this task
Use the following steps to configure the application server
and DB2 to authenticate with Kerberos:
Procedure
- Configure the DB2 Server for Kerberos authentication. Refer to DB2 Kerberos security documentation in the DB2 information
center, for example, the topic “Kerberos authentication details”.
Another helpful reference is “DB2 UDB Security, Part 6” that is located
on the IBM developerWorks website. Verify that DB2 Kerberos authentication
is working.
- Configure the application server to use Kerberos security.
See the topic “Configuring Kerberos as the authentication
mechanism using the administrative console”. Verify that application
server Kerberos authentication is working.
- Configure the DB2 data source in the application server
to use Kerberos authentication. There are two steps to
complete this task, you need to configure the resource adapter in
the application server to pass Kerberos credentials and password credentials
to the JDBC driver and secondly, you need to configure the JDBC driver
to use Kerberos authentication when connecting to the DB2 server.
For more information on completing these steps, see the topic “Configuring
a data source using the administrative console”.
Table 1. Custom
properties and values. When configuring the DB2 data source,
you must pay particular attention to the security settings and the
custom properties.Name |
Value |
kerberosServerPrincipal Note: This property
is optional except when connecting to a DB2 server that is running
on a z/OS platform (as of DB2 for LUW, v8 FP11).
|
user@REALM
or
service_name/hostname@REALM
|
SecurityMechanism Note: A value for this property
of 11, indicates that the JDBC driver needs to use Kerberos authentication
when connecting to the DB2 server.
|
11 |
- For option 2, you should configure the “Mapping-configuration
alias” to “DefaultPrincipalMapping”, or another login configuration
which does not generate GSSCredentials, and set the “Container-managed
authentication alias” to reference an alias to use for Kerberos login
by the JDBC driver. The testConnection facility also
uses this alias if no component-managed authentication alias is configured.
- For option 1, delegated Kerberos credentials, you should
configure the “Mapping-configuration alias” to “KerberosMapping”.
This will indicate that the resource adapter in the application
server should provide delegated credentials to the DB2 JDBC driver.
The testConnection facility and XA transaction recovery facility
are not able to supply delegated Kerberos credentials, but can revert
to option 2 authentication. If you do not need those features, you
can select none for each of the authentication aliases. If
testConnection is used and a valid authentication alias is configured,
an informational message, DSRA82211, is logged. This message indicates
that testConnection is not able to offer Kerberos credentials. If
no alias is configured, then testConnection fails with a Kerberos
invalid credentials error reported by the JDBC driver.
Important: If KerberosMapping is configured, but the security
component is unable to provide Kerberos credentials for a particular
connection request, the resource adapter can be configured to revert
to connection authentication using Default Principle Mapping. To configure
this fallback, select an alias from the container-managed authentication
alias list. To disable this fallback, select none from the
container-managed authentication alias list.
- To enable Kerberos mapping (option 1), you also must specify
container-managed authentication. To specify container-managed authentication,
the application must use a resource reference to lookup the data source The resource reference must specify KerberosMapping as the login
configuration. If a login configuration is specified for a resource
reference, then for application access through that resource reference,
the specified login configuration takes precedence over the mapping-configuration
alias value specified on the data source. A container-managed authentication
alias can also be specified on the resource reference.