Security plug-ins

Authentication for the Db2® database system is done using security plug-ins. A security plug-in is a dynamically loadable library that provides authentication security services.

Important: The SERVER_ENCRYPT authentication type is deprecated and might be removed in a future release.
Note: SERVER_ENCRYPT is disabled in strict FIPS mode as it is not compliant with NIST SP800-131aR2. For more information about FIPS modes, see Security Modes in Db2.
Important: The DATA_ENCRYPT authentication type is discontinued and removed as of Db2 Version 12. To encrypt data in-transit between clients and Db2 databases, we recommend that you use the Db2 database system support of TLS (Transport Layer Security). For more information, see TLS configuration of Db2.
Group retrieval plug-in
Retrieves group membership information for a particular user.
User ID/password authentication plug-in
The following authentication types are implemented using a user ID and password authentication plug-in:
  • CLIENT
  • SERVER
  • SERVER_ENCRYPT

These authentication types determine how and where authentication of a user occurs. The authentication type that is used is determined by the following method:

  • For connect or attach operations, if you specify a value for the srvcon_auth configuration parameter, then that value takes precedence over the value of the authentication configuration parameter.
  • In all other cases, the value of the authentication configuration parameter is used.
GSS-API authentication plug-in
GSS-API is formally known as Generic Security Service Application Program Interface, Version 2 (IETF RFC2743) and Generic Security Service API Version 2: C-Bindings (IETF RFC2744). The Kerberos protocol is the predominant means of implementing the GSS-API authentication mechanism. The following authentication types are implemented using GSS-API authentication plug-ins:
  • KERBEROS
  • GSSPLUGIN
  • KRB_SERVER_ENCRYPT
  • GSS_SERVER_ENCRYPT

KRB_SERVER_ENCRYPT and GSS_SERVER_ENCRYPT support both GSS-API authentication and user ID/password authentication. However, GSS-API authentication is the preferred authentication type. Client-side Kerberos support is available on AIX®, Windows, and Linux® operating systems. For Windows operating systems, Kerberos support is enabled by default.

The Db2 database manager supports these plug-ins at both the client and the server.
Note: Authentication types determine how and where a user is authenticated. To use a particular authentication type, set the value of the authentication database manager configuration parameter.

You can use each of the plug-ins independently, or with the other plug-ins. For example, you might use a specific sever-side authentication plug-in, but accept the Db2 default values for client and group authentication. Alternatively, you might have only a group retrieval, or a client authentication plug-in, but without a server-side plug-in.

If you want to use GSS-API authentication, plug-ins are required on both the client and the server.

The default behavior for authentication is to use a user ID/password plug-in that implements an operating-system-level mechanism to authenticate.

The Db2 database product includes plug-ins for group retrieval, user ID/password authentication, and GSS-API authentication. You can customize Db2 client and server authentication behavior further by developing your own plug-ins, or by purchasing plug-ins from a third party.

Deployment of security plug-ins on Db2 clients

Db2 clients can support one group retrieval plug-in and one user ID/password authentication plug-in.

Alternatively, clients using GSS-API authentication plug-in determine which plug-in to use by scanning the list of implemented GSS-API plug-ins on the Db2 server. The first authentication plug-in name that matches a GSS-API authentication plug-in implemented on the client is the one chosen. You specify the list of implemented server GSS-API plug-ins using the srvcon_gssplugin_list database manager configuration parameter. The following figure portrays the security plug-in infrastructure on a Db2 client:
Figure 1. Deploying Security Plug-ins on Db2 Clients
The Db2 client has a plug-in interface that can accept user ID/password, Kerberos, GSS-API, and Group client plug-ins.

Deployment of security plug-ins on Db2 servers

Db2 servers can support one group retrieval plug-in, one user ID/password authentication plug-in, and multiple GSS-API plug-ins. You can specify the available GSS-API plug-ins as a list of values for the srvcon_gssplugin_list database manager configuration parameter. However, only one GSS-API plug-in in this list can be a Kerberos plug-in.

In addition to deploying the server-side security plug-ins on your database server, you might have to deploy client authentication plug-ins on your database server. When you run instance-level operations, such as the db2start and db2trc commands, the Db2 database manager performs authorization checking for these operations using client authentication plug-ins. Therefore, you might need to install the client authentication plug-in that corresponds to the authentication plug-in on the server. This plug-in name is specified by the authentication database manager configuration parameter on the server.

You can set the authentication and srvcon_auth configuration parameters to different values. This scenario causes one mechanism to be used to authenticate database connections and the other mechanism to be used for local authorization.

The most common method for this approach is to:
  • Set the srvcon_auth configuration parameter to GSSPLUGIN; and
  • Set the authentication configuration parameter to SERVER.
The srvcon_auth configuration parameter is a means to override the authentication type used by incoming connections. These connections use the authentication method specified by the srvcon_auth configuration parameter, but if this value is left empty, the value of the authentication parameter is used instead.

If you do not use client authentication plug-ins on the database server, instance-level operations, such as the db2start command, fail.

The following figure outlines the security authentication plug-in infrastructure on a Db2 server:
Figure 2. Deploying Security Plug-ins on Db2 Servers
The Db2 server supports group, server, and client (local authorization) plug-ins.

Enabling security plug-ins

You can specify the plug-ins to use for each authentication mechanism by setting database manager configuration parameters. The following table outlines these parameters:
Table 1. Database Manager configuration parameters for security authentication plug-ins
Description Parameter name
Client Userid-Password Plugin CLNT_PW_PLUGIN
Client Kerberos Plugin CLNT_KRB_PLUGIN
Group Plugin GROUP_PLUGIN
GSS Plugin for Local Authorization LOCAL_GSSPLUGIN
Server Plugin Mode SRV_PLUGIN_MODE
Server List of GSS Plugins SRVCON_GSSPLUGIN_LIST
Server Userid-Password Plugin SRVCON_PW_PLUGIN
Server Connection Authentication SRVCON_AUTH
Database manager authentication AUTHENTICATION

If you do not set the values for these parameters, the default plug-ins that the Db2 product supplies are used for group retrieval, user ID/password management, and Kerberos authentication (if the authenticationparameter is set to KERBEROS on the server). However, a default GSS-API plug-in is not provided. Therefore, if you specify an authentication type of GSSPLUGIN for the authentication parameter, you must also specify a GSS-API authentication plug-in for the srvcon_gssplugin_list configuration parameter.

Loading security plug-ins

All of the supported plug-ins that are identified by the database manager configuration parameters are loaded when the database manager starts.

During connect or attach operations, the Db2 client loads a plug-in that is appropriate for the security mechanism that the client negotiated with the server. A client application can cause multiple security plug-ins to be concurrently loaded and used. This situation can occur, for example, in a threaded program that has concurrent connections to different databases from different instances. In this scenario, the client program makes an initial connection to server A that uses a GSS-API plug-in (G1). Server A sends a list of supported plug-ins to the client, and the matching G1 plug-in is loaded on the client. The client program then has another thread, which connects to server B that uses a GSS-API plug-in (G2). The client is informed about G2, which is then loaded, and now both G1 and G2 plug-ins are simultaneously in use on the client.

Actions other than connect or attach operations (such as updating the database manager configuration, starting and stopping the database manager, or turning a Db2 trace on and off) also require an authorization mechanism. For such actions, the Db2 client program loads a plug-in that is specified by another database manager configuration parameter:
  • If you set the authentication configuration parameter to GSSPLUGIN, the Db2 database manager uses the plug-in specified by the local_gssplugin configuration parameter.
  • If you set the authentication configuration parameter to KERBEROS, the Db2 database manager uses the plug-in specified by the clnt_krb_plugin configuration parameter.
  • Otherwise, the Db2 database manager uses the plug-in specified by the clnt_pw_plugin configuration parameter.

Security plug-ins are supported for connections made to the database server over both IPv4 and IPv6 address protocols.

Developing security plug-ins

If you are developing a security authentication plug-in, you must implement the standard authentication functions used by the Db2 database manager. The functionality that you must implement for the three types of plug-ins:

Group retrieval plug-in
  • Find and return the list of groups to which a user belongs
User ID/password authentication plug-in
  • Identify the default security context (for a client plug-in only)
  • Validate and, optionally, change a password
  • Determine whether a particular string represents a valid user (for a server plug-in only)
  • Modify the user ID or password that is provided on the client before it is sent to the server (for a client plug-in only)
  • Return the Db2 authorization ID that is associated with a particular user
GSS-API authentication plug-in
  • Identify the default security context (for a client plug-in only)
  • Implement the required GSS-API functions
  • Generate initial credentials based on a user ID and password and, optionally, change a password (for a client plug-in only)
  • Create and accept security tickets
  • Return the Db2 authorization ID that is associated with a particular GSS-API security context
You can pass a user ID of up to 255 characters for a connect statement that you issue through the CLP or via a dynamic SQL statement.
Important: The integrity of your Db2 database system installation can be compromised if security plug-ins are not adequately coded, reviewed, and tested. The Db2 database product takes precautions against many common types of failures, but it cannot guarantee complete integrity if user-written security plug-ins are deployed.