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.
- 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
- DATA_ENCRYPT
- DATA_ENCRYPT_CMP
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 Solaris, AIX®, HP-UX (64-bit only), Windows, and Linux® operating systems. For Windows operating systems, Kerberos support is enabled by default.
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.
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.
- Set the srvcon_auth configuration parameter to GSSPLUGIN; and
- Set the authentication configuration parameter to SERVER.
If you do not use client authentication plug-ins on the database server, instance-level operations, such as the db2start command, fail.
Enabling security 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.
- 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