DB2 Version 9.7 for Linux, UNIX, and Windows

Deploying a GSS-API plug-in

To customize the DB2® security system's authentication behavior, you can develop your own authentication plug-ins using the GSS-API, or buy one from a third party.

Before you begin

In the case of plug-in types other than Kerberos, you must have matching plug-in names on the client and the server along with the same plug-in type. The plug-ins on the client and server need not be from the same vendor, but they must generate and consume compatible GSS-API tokens. Any combination of Kerberos plug-ins deployed on the client and the server is acceptable since Kerberos plug-ins are standardized. However, different implementations of less standardized GSS-API mechanisms, such as x.509 certificates, might only be partially compatible with DB2 database systems. Depending on their intended usage, all GSS-API authentication plug-ins must be placed in either the client plug-in directory or the server plug-in directory. If a plug-in is placed in the client plug-in directory, it will be used for local authorization checking and when a client attempts to connect with the server. If the plug-in is placed in the server plug-in directory, it will be used for handling incoming connections to the server and for checking whether an authorization ID exists and is valid whenever the GRANT statement is issued without specifying either the keyword USER or GROUP.

Note: You must stop the DB2 server or any applications using the plug-ins before you deploy a new version of an existing plug-in. Undefined behavior including traps will occur if a process is still using a plug-in when a new version (with the same name) is copied over it. This restriction is not in effect when you deploy a plugin for the first time or when the plug-in is not in use.

After you acquire GSS-API authentication plug-ins that are suitable for your database management system, you can deploy them.

Procedure

To deploy a GSS-API authentication plug-in on the database server, perform the following steps on the server:
1. Copy the GSS-API authentication plug-in library in the server plug-in directory. You can copy numerous GSS-API plug-ins into this directory.
2. Update the database manager configuration parameter srvcon_gssplugin_list with an ordered, comma-delimited list of the names of the plug-ins installed in the GSS-API plug-in directory.
3. Either:
  - Setting the database manager configuration parameter srvcon_auth to GSSPLUGIN or GSS_SERVER_ENCRYPT is a way to enable the server to use GSSAPI PLUGIN authentication method. Or:
  - Setting the database manager configuration parameter srvcon_auth to NOT_SPECIFIED and setting authentication to GSSPLUGIN or GSS_SERVER_ENCRYPT is a way to enable the server to use GSSAPI PLUGIN authentication method.
To deploy a GSS-API authentication plug-in on database clients, perform the following steps on each client:
1. Copy the GSS-API authentication plug-in library in the client plug-in directory. You can copy numerous GSS-API plug-ins into this directory. The client selects a GSS-API plug-in for authentication during a CONNECT or ATTACH operation by picking the first GSS-API plug-in contained in the server's plug-in list that is available on the client.
2. Optional: Catalog the databases that the client will access, indicating that the client will only accept a GSS-API authentication plug-in as the authentication mechanism. For example:
```
CATALOG DB testdb AT NODE testnode AUTHENTICATION GSSPLUGIN
```
For local authorization on a client, server, or gateway using a GSS-API authentication plug-in, perform the following steps:
1. Copy the GSS-API authentication plug-in library in the client plug-in directory on the client, server, or gateway.
2. Update the database manager configuration parameter local_gssplugin with the name of the plug-in.
3. Set the authentication database manager configuration parameter to GSSPLUGIN, or GSS_SERVER_ENCRYPT.