To create a DB2 UDB security plug-in

Creating a DB2 UDB Security plug-in requires 6 steps. The following subsections explain each step in detail: include the header file of the security plug-in in the plug-in: Sqllib/include/db2secplugin.h sqllib/include/gssapidb2.h Note: Only if the implementation is based on GSS Security plug-in to GssapiDB2.h. Write the APIs that make up the plug-in. You need to write an appropriate initialization API and some other APIs required by the server, client, or group plug-in. Fills the function pointer structure before returning DB2. Indicates the plug-in API version used by the plug-in. Indicates the plug-in type, such as User ID password, GSS, Kerberos. Compile the plug-in source code and create a shared library. Compiled to 32-bit or 64-bit based on application/server instance. Place this library in the appropriate directory. Enable the plug-in by updating the database manager parameters. Step 1: Include the security plug-in header file into the plug-in db2secPlugin.h and GssapiDB2.h are the two header files required to implement the custom security plug-in. The GssapiDB2.h header file is required only when building the GSS plug-in. Figure 5 shows the location of the two header files required to implement the security plug-in on a Windows system. Figure 5. The location of the plug-in header file on the Windows system 498) this.width=498 ' OnMouseWheel = ' javascript:return big (This) ' height=446 alt= ' windows The location of the plug-in header file on the system "src="/files/uploadimg/20061213/1752000.jpg "width=372> Step 2: Write the APIs that make up the plug-in based on whether you are creating a server plug-in, a client plug-in, or a group plug-in. The following APIs need to be written separately to initialize the plug-in: Db2secserverauthplugininit Db2secclientauthplugininit Db2secgroupplugininit For example, you can write Db2secserverauthplugininit API: Listing 1. DB2SECSERVERAUTHPLUGININITSQL_API_RC sql_api_fn db2secserverauthplugininit (db2int32 version, void Server_fns, DB2SEcgetcondetails* Getcondetails_fn, db2seclogmessage* logmessage_fn, char** errormsg, db2int32* errormsglen) {struct Userid_password_server_auth_functions_1 *fns = (struct userid_password_server_auth_functions_1*) Server_fns; CONDETAILS_FN = GETCONDETAILS_FN; LOGMESSAGE_FN = LOGMESSAGE_FN; Fns->version = db2sec_api_version; Fns->plugintype = Db2sec_plugin_type_userid_password; Fns->db2secdoesauthidexist = &is_user; Fns->db2secfreeerrormsg = &free_error_message; Fns->db2secfreetoken = &free_token; Fns->db2secgetauthids = &getauthids; Fns->db2secserverauthpluginterm = &terminate_plugin; Fns->db2secvalidatepassword = &validatePassword; /* Example on LOGMESSAGE_FN/* would log the init successful information into Db2diag.log at Diaglevel 3/* ( LOGMESSAGE_FN) (db2sec_log_warning, "Db2secserverauthplugininit successful", strlen ("Db2secserverauthplugininit Successful ")); return DB2SEC_PLUGIN_OK; DB2 call Db2secserverauthplugininit AP after loadingI to initialize the server plug-in library. The preceding code comes from file Txtserver.c, which is included in the zip file later in this article. In addition to initializing functions, you need to implement some plug-in APIs for server, client, and group Plug-ins. In addition, there are specific APIs for user ID password authentication and for GSS authentication. Figure 6, Figure 7, and Figure 8 describe the functions of these functions. Note: The DB2 UDB Manual contains a section detailing how to develop security plug-ins and explains the security plug-in API. Those details are beyond the scope of this article. This section simply provides an overview of the plug-in API. Figure 6. Group member Lookup plugin 498) this.width=498 ' OnMouseWheel = ' javascript:return big (This) ' height=404 alt= groups members find plug-in src= '/files/uploadimg /20061213/1752001.gif "width=104> Figure 7. Client plug-in 498) this.width=498 ' OnMouseWheel = ' javascript:return big (This) ' height=409 alt= client plug-in src= '/files/uploadimg/ 20061213/1752002.gif "Width=413> Figure 8. Server plugin 498) this.width=498 ' OnMouseWheel = ' javascript:return big (This) ' height=409 alt= server plugin src= '/files/uploadimg/ 20061213/1752003.gif "width=414> Step 3: Fill the function pointer structure function pointer before returning to DB2 returns pointers to all APIs required for a particular plug-in library that you implement. For example, for a group plug-in, it contains points to db2secdoesgroupexist, db2secfreeerrormsg, Db2secfreegrouplistmemory, Db2secgetgroupsforuser, and A pointer to the implementation of the Db2secpluginterm API. The txtgroup.c file in the zip file that is included later in this article provides an example of how to populate the function pointers for the Group Plug-in library. The following is a fragment of the code. Fns->version = db2sec_api_version;fns->db2secdoesgroupexist = &is_group;fns->db2secfreeerrormsg = &free_error_message;fns-> Db2secfreegrouplistmemory = &free_group_list;fns->db2secgetgroupsforuser = &get_groups;fns-> Db2secpluginterm = &terminate_plugin; Step 4: Compile the plug-in source code and create a shared library after you write a security plug-in, compile it into a 32-bit or 64-bit file based on the DB2 instance. The library name must be the same as the plug-in name. Also, the library must be a shared library with the appropriate platform-specific extensions. For example, if the plug-in name is Myplugin, you should use the following extension: MyPlugin.dll (Windows) Myplugin.a (AIX) myplugin.so (Linux, AIX, Sun Solaris, HP-UX) The MYPLUGIN.SL (HP-UX) library must be thread-safe (reentrant) and must use C-link (at least for the initialization function to use the C link). Step 5: Put the library into the appropriate directory you must put the security plug-in library into a specific directory: Windows:sqllib\security\plugin\<instance name>\client sqllib\security\plugin \<instance name>\server sqllib\security\plugin\<instance name>\group for IBM-supplied default plug-ins: sqllib\security\ Plugin\ibm\client Sqllib\security\plugin\ibm\server Sqllib\security\plugin\ibm\group 32-bit Linux and unix:sqllib/ Security32/plugin/client sqllib/security32/plugin/server Sqllib/security32/plugin/group for IBM-supplied default plug-ins: sqllib/ Security32/plugin/ibm/client Sqllib/security32/plugin/ibm/server Sqllib/security32/plugin/ibm/group in Linux and UNIX, for 64-bit libraries, it also uses a directory similar to the previous one, just to use the subdirectory name Security64, not security32. In a Windows 64-bit instance, both the 32-bit and 64-bit plug-ins are in the same directory, but 64-bit plug-ins will be appended with the suffix ' 64 ', such as Myplugin64.dll. Note: IBM subdirectories (under the plug-in directory) are reserved for the default plug-ins provided by IBM. Any other custom plug-ins placed in the directory will be ignored. Step 6: Enable the plug-in by updating the database Manager parameter before version 8.2, the authentication Database Manager configuration parameter specifies the location and mechanism by which to perform Connect/attach, group queries, and local authorization checks. There are more configuration parameters in version 8.2, which provides greater flexibility to select authentication options. Table 2 provides a list of database Manager configuration parameters that are applied to plug-ins and explains how they apply to security plug-ins. Table 2. Security Plug-in Database Manager configuration Parameters Description Parameter name Description 1 Client User ID password plug-in (clnt_pw_plugin) If the value is set on the client and the authentication parameter on the server is set to client, This parameter specifies the user ID password plug-in for the authentication performed on the client computer. If this value is set on the server, this parameter specifies the user ID password plug-in for the instance operation (for example, Db2start) authorization check. During a database connection (local area Connection) that is issued locally on the database server, you can also use the Client Plug-in 2 client-side plugin (clnt_krb_plugin) value on the database server to specify Kerberos for client authentication and local authorization The name of the plug-in library. This plug-in is used when authenticating a client using KERBEROS or Krb_server_encrypt authentication. The default value on Windows is IBMkrb5. On other platforms, the default value is the NULL3 Group plug-in (Group_plugin) The value of this parameter specifies the Group plug-in Library 4 for the group member lookup for the local authorization of the GSS plug-in (Local_gssplugin) when the database Manager configuration parameters The value of the authentication is set to Gssplugin or Gss_servWhen Er_encrypt, the value of this parameter specifies the name of the GSS plug-in library for instance-level local authorization. Gssplugin indicates that the server will only authenticate using the GSS plug-in that is familiar to it. Gssplugin_server_encrypt indicates that the server will accept additional encrypted user ID password requests. This type is primarily a 5 server plug-in mode (Srv_plugin_mode) provided for backward compatibility, which specifies whether to run in fenced or unfenced mode. The default value (the only supported value) is the UNFENCED6 server GSS list of plug-ins (srvcon_gssplugin_list) This parameter specifies the list of GSS plug-in libraries supported by the database server, with a comma as the delimiter in the list. This list can contain only one Kerberos plug-in. If the parameter value is not set and the authentication is set to KERBEROS or Krb_svr_encrypt, the default DB2 Kerberos plug-in (IBMKRB5) 7 Server user ID password plug-in will be used (srvcon_pw_ PLUGIN the value of this parameter specifies the user ID password plug-in library 8 server connection authentication (Srvcon_auth) for server-side authentication The value of this parameter is used only for connections. It overwrites the authentication method specified in authentication. The local instance operation still uses the operation specified in authentication. The default value is NOT_SPECIFIED9 Database Manager authentication (authentication) The value of this parameter specifies how user authentication is performed and where it is performed in order to check local instance authorization. The default value is Server table 3, which shows the steps to enable the User ID password Authentication plug-in using the configuration parameters listed earlier. Table 3. To enable the User ID password Authentication plug-in step on the client steps 1 on the server to update Clnt_pw_plugin with the name of the client plug-in. If Clnt_pw_plugin is empty, it will use its default value Ibmosauthclient, which is an IBM-supplied plug-in update with the name of the server plug-in srvcon_pw_plugin2 will Srvcon_auth Set to a type of system authentication (CLIENT, SERVER, Server_encrypt, Data_encrypt, or data_encrypt_cmp), or set Srvcon_auth to Not_specified andUthentication is set to a system authentication type. If Srvcon_pw_plugin is empty, it will use its default value Ibmosauthserver, which is the IBM-provided plug-in table 4 shows the steps to enable a group member lookup plug-in using the configuration parameters listed earlier. Table 4. To enable a group member lookup plug-in step on the client steps 1 on the server to update Group_plugin with the name of the group plug-in. If Group_plugin is empty, it will use its default value ibmosgroups, which is an IBM-supplied plug-in update group_plugin with the name of the group plug-in. If Group_plugin is empty, it will use its default value ibmosgroups, which is the IBM-provided plug-in table 5 shows the steps to enable the GSS authentication plug-in using the configuration parameters listed earlier. Table 5. To enable the GSS authentication plug-in step on the client computer Step 1 puts the plug-in library in the client plug-in directory to place the plug-in library in the server plug-in directory 2 optional: catalog (catalog) A database indicates that the client will authenticate with only one GSS plug-in. For example: DB2 catalog DB TESTDB at Node Testnode authentication gssplugin. Multiple plug-ins can exist on a single client. In this case, the server will indicate which plug-in is being used to update the srvcon_gssplugin_list with an ordered list of supported plug-in names. To enable the GSS plug-in, you can either set the Srvcon_auth to Gssplugin, or set the Srvcon_auth to Not_specified and set authentication to Gssplugin. To enable local authorization: Put the client plug-in library into the client plug-in directory. Update Local_gssplugin with plug-in name. Table 6 shows the steps to enable the Kerberos authentication plug-in using the configuration parameters listed earlier. Table 6. To enable the Kerberos plug-in step on the client, step 1 on the server, place the plug-in library in the client plug-in directory place the plug-in library in the server plug-in directory 2 with the name of the Kerberos plug-in update clnt_krb_plugin. If Clnt_krb_plugin is empty, then DB2 considers the client to be unable to use Kerberos. The default Kerberos plug-in provided by DB2 is named IBMkrb5。 For a platform that supports Kerberos, the IBMKRB5 library is already in the client plug-in directory. To update srvcon_gssplugin_list3 with the server Kerberos plug-in name: Cataloging a database indicates that the client will use the Kerberos plug-in for authentication. For example: DB2 catalog DB TESTDB at node Testnode authentication Kerberos target principal Service/host@realm set Srvcon_auth to KER Beros or Krb_server_encrypt, or set Srvcon_auth to not_specified and set authentication to KERBEROS or krb_server_encrypt the responsible editor Zhao Zha Oyi#51cto.com TEL: (010) 68476636-8001 to force (0 votes) is tempted (0 Votes) nonsense (0 Votes) Professional (0 Votes) The title party (0 Votes) passing (0 Votes) Text: Steps to create a DB2 UDB security plug-in back to network security home