GSS-API

The GSS-API is fully described in RFC 2743, which, unfortunately, is among the most difficult RFCs to understand.

The figure shows three DB2 clients using different GSS-API plug-ins, and a DB2 server with a list of the GSS-API plug-ins it supports.

GSS-API is a standard that addresses the issue of the existence of similar but incompatible security services in use today.

They also do not support the GSS-API plug-in authentication method, except Kerberos.

GSS_SERVER_ENCRYPT - This specifies that the server accepts GSS API-based plug-in authentication or encrypted server authentication schemes.

Thus, a secure application developed using GSS-API can work over different security mechanisms without changes to the application.

Table 7 provides a simplified illustration of the basic client-server flows involved in the GSS-API authentication process.

Update the database manager configuration parameter srvcon_gssplugin_list with the ordered list of the supported GSS-API plug-in name.

To configure the client, simply copy the GSS-API plug-in into the client plug-in directory.

Kerberos is the most popular underlying security mechanism available with GSS-API.

Almost all UNIX operating systems, including AIX, support and provide GSS-API.

The GSS-API default behavior will be to initiate the context for Kerberos security mechanism.

This article takes you further with information about the new GSS-API security mechanisms.

At the server, an ordered list of GSS-API plug-ins is specified in the SRVCON_GSSPLUGIN_LIST database manager configuration parameter.

This typically will be documented in detail by the GSS-API offering that supports LIPKEY mechanism.

Using these GSS-API interfaces, you can implement secure Keberized applications and systems.

On the DB2 UDB server: an X. 509 certificate, a PKI environment, and a LIPKEY-enabled server-side GSS-API security plug-in.

On the DB2 UDB client: an X. 509 certificate, a PKI environment, and a SPKM-enabled client-side GSS-API security plug-in.

GSS-API is a generic API to perform client-server authentication.

Table 8 shows the steps involved in a client-server flow when DB2 is involved in the GSS-API authentication process.

There are other forms of credentials, depending on the specific GSS-API implementation.

A programmer using GSS-API can write an application that is ignorant of the details of protecting network data.

Table 5 shows the steps you would take to enable GSS-API authentication plug-ins using the above listed configuration parameters.

Kerberos and PKI already support GSS-API, and in fact, Kerberos authentication in DB2 is implemented using the GSS-API model.

The gssapiDB2. h header file is needed only if you are building a GSS-API plug-in.

SPKM is a GSS-API mechanism which is based on a public key rather than a symmetric key infrastructure.

So for applications that need to have a GSS-API mechanism which is based on a public-key infrastructure, SPKM is the answer.

For GSS-API or Kerberos, this is the password that is used to get the user credential.

Install the server-side GSS-API plug-in (for example, krb, gss1, or gss2, or any combination) in the server plug-in directory.

The following is the API calling sequence if a Kerberos or GSS-API-based authentication plug-in is in use

Example 4: Using the Kerberos plug-in to further explain the DB2 implementation of GSS-API standard and DB2 specific extension

Scenario 1: Use of down-level and upgraded clients with GSS-API plug-in