Implementing Security

Copyright © Cloud Software Group, Inc. All Rights Reserved

Chapter 1 Installing Service Gateway for DB2 : Implementing Security

Implementing Security

The Gateway provides two methods of authorizing access to DB2 data:

•

DB2 Subsystem

•

External security interface

The method used is determined by the SECLEVEL parameter specified at startup time. For details, see Gateway Parameters.

Methods of Authorizing Access to DB2 Data

DB2 Subsystem

(SECLEVEL=0)

The DB2 subsystem verifies all DB2 table accesses using the ID that started the Gateway (if the Gateway is running as a batch job) or the started task name (if the Gateway is running as a started task). This ID or started task name requires the security described in DB2 Security below.

External security interface

(SECLEVEL=1)

DB2 table access is verified using the TIBCO Object Service Broker session ID or the current group name. The external security interface is implemented using the sample IDENTIFY AUTHORIZATION EXIT DSN3@ATH. Refer to Implementing External Security for more information. TIBCO Object Service Broker session IDs or group names require security as described in DB2 Security below.

DB2 Security

The following table lists required DB2 security for the listed tasks:

Task

DB2 Security

Defining TIBCO Object Service Broker DB2 tables

EXECUTE authorization on the Gateway plan.

SELECT authorization on SYSIBM.SYSTABLES, SYSIBM.SYSCOLUMNS, @SYSROUTINES and @SYSPARMS.

Accessing DB2 data

EXECUTE authorization on the Gateway plan.

Appropriate authorization (SELECT, INSERT, UPDATE, DELETE or ALL) to all DB2 tables to be accessed from TIBCO Object Service Broker using Dynamic SQL.

Note After generating Static SQL for a DB2 table, the Gateway always attempts to access this table using Static SQL. Dynamic SQL is used as described in Conditions Under Which Dynamic SQL is Used.

When Static SQL is used, only EXECUTE authority on the Gateway plan is required.

When Dynamic SQL is used, both EXECUTE authority on the Gateway plan and individual table authorizations are required.

TIBCO Object Service Broker Security

To restrict the ability to define TIBCO Object Service Broker DB2 tables, restrict read access to the TIBCO Object Service Broker tables that map to SYSIBM.SYSTABLES, SYSIBM.SYSCOLUMNS, SYSIBM.SYSROUTINES and SYSIBM.SYSPARMS (that is, @SYSTABLES, @SYSCOLUMNS, @SYSROUTINES and @SYSPARMS). For more information on restricting access to existing DB2 tables, refer to TIBCO Object Service Broker Managing Security.

Considering Fail Safe Processing

To guarantee consistency when updating both TDS and DB2 data from a single instance of the Gateway in a single transaction, you must use Fail Safe level‑1 processing. For more information, refer to Implementing Fail Safe Processing.

DB2 Subsystem (SECLEVEL=0)	The DB2 subsystem verifies all DB2 table accesses using the ID that started the Gateway (if the Gateway is running as a batch job) or the started task name (if the Gateway is running as a started task). This ID or started task name requires the security described in DB2 Security below.
External security interface (SECLEVEL=1)	DB2 table access is verified using the TIBCO Object Service Broker session ID or the current group name. The external security interface is implemented using the sample IDENTIFY AUTHORIZATION EXIT DSN3@ATH. Refer to Implementing External Security for more information. TIBCO Object Service Broker session IDs or group names require security as described in DB2 Security below.

Task	DB2 Security
Defining TIBCO Object Service Broker DB2 tables	EXECUTE authorization on the Gateway plan. SELECT authorization on SYSIBM.SYSTABLES, SYSIBM.SYSCOLUMNS, @SYSROUTINES and @SYSPARMS.
Accessing DB2 data	EXECUTE authorization on the Gateway plan. Appropriate authorization (SELECT, INSERT, UPDATE, DELETE or ALL) to all DB2 tables to be accessed from TIBCO Object Service Broker using Dynamic SQL. Note After generating Static SQL for a DB2 table, the Gateway always attempts to access this table using Static SQL. Dynamic SQL is used as described in Conditions Under Which Dynamic SQL is Used. When Static SQL is used, only EXECUTE authority on the Gateway plan is required. When Dynamic SQL is used, both EXECUTE authority on the Gateway plan and individual table authorizations are required.