DB2 10.5 for Linux, UNIX, and Windows
DB2 10.5 for Linux, UNIX, and Windows
There are certain restrictions on the use of security plug-ins.
You cannot use a GSS-API plug-in to authenticate connections between DB2® clients on Linux, UNIX, and Windows and another DB2 family servers such as DB2 for z/OS®. You also cannot authenticate connections from another DB2 database family product, acting as a client, to a DB2 server on Linux, UNIX, or Windows.
If you use a DB2 client on Linux, UNIX, or Windows to connect to other DB2 database family servers, you can use client-side user ID/password plug-ins (such as the IBM shipped operating system authentication plug-in), or you can write your own user ID/password plug-in. You can also use the built-in Kerberos plug-ins, or implement your own.
With a DB2 client on Linux, UNIX, or Windows, you should not catalog a database using the GSSPLUGIN authentication type.
Restrictions on the authorization ID: In DB2 Version 9.5 and later, you can have a 128-byte authorization ID. However, when the authorization ID is interpreted as an operating system user ID or group name, DB2 imposed naming restrictions apply. For example, the Linux and UNIX operating systems can contain up to 8 characters and the Windows operating systems can contain up to 30 characters for user IDs and group names. Therefore, if you want to connect as a user that has a 128-byte authorization ID, you need to write your own security plug-in. In the plug-in, you can use the extended sizes for the authorization ID. For example, you can give your security plug-in a 30-byte user ID and, during authentication, it returns a 128-byte authorization ID that you can connect to.
DB2 II does not support the use of delegated credentials from a GSS_API plug-in to establish outbound connections to data sources. Connections to data sources must continue to use the CREATE USER MAPPING command.
The DB2 Administration Server (DAS) does not support security plug-ins. The DAS only supports the operating system authentication mechanism.
When developing security plug-ins that will be deployed in DB2 clients on Windows operating systems, do not unload any auxiliary libraries in the plug-in termination function. This restriction applies to all types of client security plug-ins, including group, user ID and password, Kerberos, and GSS-API plug-ins. Since these termination APIs such as db2secPluginTerm, db2secClientAuthPluginTerm and db2secServerAuthPluginTerm are not called on any Windows platform, you need to do the appropriate resource cleanup.
This restriction is related to cleanup issues associated with the unloading of DLLs on Windows.
On AIX®, security plug-in libraries can have a file name extension of .a or .so. The mechanism used to load the plug-in library depends on which extension is used:
Plug-in libraries with file name extensions of .a are assumed to be archives containing shared object members. These members must be named shr.o (32-bit) or shr64.o (64-bit). A single archive can contain both the 32-bit and 64-bit members, allowing it to be deployed on both types of platforms.
For example, to build a 32-bit archive style plug-in library:
xlc_r -qmkshrobj -o shr.o MyPlugin.c -bE:MyPlugin.exp
ar rv MyPlugin.a shr.oPlug-in libraries with file name extensions of .so are assumed to be dynamically loadable shared objects. Such an object is either 32-bit or 64-bit, depending on the compiler and linker options used when it was built. For example, to build a 32-bit plug-in library:
xlc_r -qmkshrobj -o MyPlugin.so MyPlugin.c -bE:MyPlugin.expOn all platforms other than AIX, security plug-in libraries are always assumed to be dynamically loadable shared objects.
Message encryption and signing is not available in GSS-API security plug-ins.