Unit 11.

Federated Databases --------------------------------------------------------DB2 : DB2 DB2 DB2 IBM IBM LUW supports federation among the IBM family of database products, including Universal Database (UDB) for Linux, UNIX, and Windows for z/OS for iSeries Informix IDS Informix XPS

What Is a Federated System? --------------------------------------------------------------------A federated system consists of: A DB2 instance that operates as a federated server One or more data sources A database that acts as the federated database Clients (users and applications) that access the federated database and data sources with a federated system, you can send distributed requests to multi ple data sources within a single SQL statement. For example, you can join data t hat is located in a DB2 UDB table, an Oracle table, and a Sybase view in a singl e SQL statement. Federated Server: --------------------------------------------------------------------The federated server is a database manager instance to which application process es connect and submit requests. Any number of DB2 instances can be configured to function as federated servers. You can use existing DB2 instances as your feder ated server, or you can create new ones specifically for the federated system. T he DB2 federated instance that manages the federated system is called a server b ecause it responds to requests from end users and client applications. Federated Database: ---------------------------------------------------------------------Users and applications interface with the federated database managed by the fede rated server. The federated database contains catalog entries that identify data sources and their characteristics. The federated database system catalog contains: - Information about objects at the data sources. - Information about the objects in the federated database. - The catalog in a federated database is called the global catalog becau se it contains information about the entire federated system. - DB2 query optimizer uses the information in the global catalog and the data source wrapper to plan the best way to process SQL statements. - The information stored in the global catalog includes remote and local information, such as column names, column data types, column default values, an d index information. Pass-Through Sessions: ---------------------------------------------------------------------In a federated system, a special DB2 session submits SQL statements directly to data sources, using the SQL dialect associated with that data source. For example, use a pass-through session to create a procedure, create an index, or perform queries in the native dialect of the data source.

CREATE USER MAPPING FOR USER SERVER SYBSERVER OPTIONS (REMOTE_AUTHID 'xxxxxxxx', REMOTE_PASSWORD 'yyyyyyyy'); Wrappers and Wrapper Options: --------------------------------------------------------------------------------Wrappers are mechanisms by which the federated server interacts with data source s. The federated server uses routines stored in a library called a wrapper modul e to implement a wrapper. These routines allow the federated server to perform o perations such as connecting to a data source and retrieving data from it iterat ively. Typically, the DB2 federated instance owner uses the CREATE WRAPPER state ment to register a wrapper in the federated system. create WRAPPER sqlnet; Data Source DB2 UDB for Linux, UNIX, and Windows DB2 UDB for z/OS and OS/390 DB2 UDB for iSeries DB2 UDB for VM and VSE Informix Oracle Microsoft SQL Server ODBC Sybase Default Wrapper Name(s) DRDA DRDA DRDA DRDA INFORMIX SQLNet or Net8 no default OLEDB CTLIB, DBLIB

Server Definitions: --------------------------------------------------------------------------------------After wrappers are created for the data sources, the federated instance owner de fines the data sources to the federated database. The instance owner supplies a name to identify the data source and other information that pertains to the data source. If the data source is an RDBMS, this information includes: The type and version of the RDBMS The database name for the data source on the RDBMS Metadata that is specific to the RDBMS

User Mappings and User Options: ---------------------------------------------------------------------------------------When a federated server needs to push down a request to a data source, the serve r must first establish a connection to the data source. The server does this by using a valid user ID and password to that data source. Nicknames and Data Source Objects:

---------------------------------------------------------------------------------------After you create the server definitions and user mappings, the federated instanc e owner creates the nicknames. A nickname is an identifier that is used to refer ence the object located at the data sources that you want to access. The objects that nicknames identify are referred to as data source objects.

Federated Lab: ----------------------------------------------------------------------------------------Step #1: Enable federation in your DB2 instance by issuing the following command from a DB2 command window: db2 update database manager configuration using federated yes Step #2: db2stop and db2start Step #3: Create database sample db2sampl -force Step #4: Create databasee Federate db2 "create database federate" Step #5: Connect to federate database db2 "connect to federate" Step #6: Create a sample table db2 "create table greeting (deptno char(3), dept_greeting char(6))" db2 "insert into greeting values('E21', 'Howdy')" Step #7: Let's create our federated objects db2 "drop wrapper drda" db2 "create wrapper drda" Step #8: The add dbname option is a DB2 alias from the database directory where the federated server runs. create server mysample type db2/udb version '9.7' wrapper drda authid "<username>" password "<mypassword>" options( add dbname 'SAMPLE'); Step #9: Create user mapping create user mapping for user server mysample options ( remote_authid '<username>',

remote_password '<mypassword>'); Step #10: Create nick names create nickname myemp for mysample.db2inst1.employee; create nickname mydept for mysample.db2inst1.department; Step #11: Run your SQL statements on federated database --- Query 1: Select from just one nickname. -select ee.empno, ee.firstnme, ee.workdept from myemp ee order by ee.workdept; --- Query 2: Join our local table with a nickname -select gg.dept_greeting, ee.firstnme from greeting gg, myemp ee where gg.deptno=ee.workdept order by ee.lastname; --- Query 3: Join two nicknames -select ee.empno, ee.lastname, ee.firstnme, dd.deptname from myemp ee, mydept dd where dd.deptno='E21' and ee.workdept=dd.deptno order by ee.lastname;

DB2 Security: -------------------------------------------------------------------------------------Authentication and Authorization ---------------------------------------------------Authorization can be given to users in the following categories: 1. System-level authorization (SYSADM, SYSCTRL, SYSMAINT, SYSMON) 2. Database-level authorization (SECADM, DBADM, ACCESSCTRL, DATAACCESS, SQLADM, WLMADM, EXPLAIN, LOAD, CONNECT) 3. Object Level Authorization (Normal SELECT, INSERT, UPDATE, etc..) 4. Content Based Authorization (LBAC) Authentication Types: 1. SEVER 2. SERVER_ENCRYPT 3. CLIENT 4. DATA_ENCRYPT 5. DATA_ENCRYPT_CMP 6. KERBEROS 7. KRB_SERVER_ENCRYPT 8. GSSPLUGIN

9. GSS_SERVER_ENCRYPT SYSADM - Update and restore a database manager configuration parameters (DBM CFG) inclu ding specifying groups that have SYSADM, SYSCTRL, SYSMAINT AND SYSMON - Grant and revoke table space privileges - Upgrade and restore a database SYSCTRL - Update a database, node, or distributed connection services (DCS) directory - Restore to a new or existing database - Force users off the system - Create or drop a database (NOTE: automatically gets DBADM authority) - Create, drop, or alter a table space - Restore to a new or existing database - Use any table space SYSMAINT - Back up a database or table space - Restore to an existing database - Roll forward recovery - Start or stop an instance - Restore or quiesce a table space, and query it s state - Run tracing - Database system monitor snapshots - Reorganize tables - Use RUNSTATS and update log history files SYSMON - GET DATABASE MANAGER MONITOR SWITCHES - GET MONITOR SWITCHES - GET SNAPSHOT - LIST commands: ACTIVE DATABASES, APPLICATIONS, DATABASE PARTITION GROUPS, DCS APPLICATIONS, PACKAGES, TABLES, TABLESPACE CONTAINERS, TABLESPACES, UTILITIES-- RESET MONITOR - UPDATE MONITOR SWITCHES - APIs: db2GetSnapshot and db2GetSnapshotSize, db2MonitorSwitches, db2mtrk, db2ResetMonitor - All snapshot table functions, without running SNAP_WRITE_FILE - Can connect to a database SECADM Create, alter, drop and comment on security objects - Grant and revoke all privileges and authorities - TRANSFER OWNERSHIP statement - EXECUTE privilege on audit system-defined routines - Grant EXECUTE privilege on audit system-defined routines - AUDIT statement - SELECT privilege on system catalog tables and views - CONNECT authority ACCESSCTRL - SELECT privilege on system catalog tables and views - Grant and revoke SQLADM, WLMADM, EXPLAIN, BINDADD, CONNECT, CREATETAB, CREATE_EXTERNAL_ROUTINE, CREATE_NOT_FENCED_ROUTINE, IMPLICIT_SCHEMA,

LOAD, QUIESCE_CONNECT - Grant and revoke all privileges on global variables, indexes, nicknames, packages, routines (except system-defined audit routines), schemas, sequences, servers, tables, table spaces, views, XSR objects DATAACCESS - LOAD authority - SELECT, INSERT, UPDATE, AND DELETE privileges on all tables, views, MQTs, and nicknames - SELECT privilege on system catalog tables and views - EXECUTE privilege on all routines (except system-defined audit routines) - EXECUTE privilege on all packages DBADM - Create, alter, drop non-security-related objects - Read log files - Create, activate, drop event monitors - Query the state of a table space - Update log history files - Quiesce a table space - Reorganize indexes/tables - Use RUNSTATS - BINDADD authority - CONNECT authority - CREATETAB authority - CREATE_EXTERNAL_ROUTINE authority - CREATE_NOT_FENCED_ROUTINE authority - IMPLICIT_SCHEMA authority - LOAD authority - QUIESCE_CONNECT authority SQLADM - CREATE EVENT MONITOR - DROP EVENT MONITOR - FLUSH EVENT MONITOR - SET EVENT MONITOR STATE - FLUSH OPT. PROFILE CACHE - FLUSH PACKAGE CACHE - PREPARE - REORG INDEXES/TABLES - RUNSTATS - EXECUTE privilege on all system-defined routines (except audit routines) - SELECT priv on sys catalog tables and views - EXPLAIN - Certain clauses of ALTER SERVICE CLASS, ALTER THRESHOLD, ALTER WORK ACTION SET , ALTER WORKLOAD

WLMADM - Create, alter, comment on and drop workload manager objects - Grant and revoke workload privileges - EXECUTE privilege on the system-defined workload management routines EXPLAIN - EXPLAIN statement

- PREPARE statement - EXECUTE privilege on the system-defined explain routines

Secured Socket Layer(SSL): ---------------------------------------------------------------------DB2COMM registry variable is set to TCPIP, SSL SSL_SVCENAME new DBM CFG IBM Global Security Kit (GSKit) libraries LIBPATH, SHLIB_PATH or LD_LIBRARY_PATH Database Audit: ---------------------------------------------------------------------The security administrator can use the following audit routines to perform the s pecified tasks: - The SYSPROC.AUDIT_ARCHIVE stored procedure archives audit logs. - The SYSPROC.AUDIT_LIST_LOGS table function allows you to locate logs o f interest. - The SYSPROC.AUDIT_DELIM_EXTRACT stored procedure extracts data into de limited files for analysis. Example of auditing any actions by SYSADM or DBADM: ----------------------------------------------------------CREATE AUDIT POLICY ADMINSPOLICY CATEGORIES EXECUTE STATUS BOTH, SYSADMIN STATUS BOTH ERROR TYPE AUDIT COMMIT AUDIT SYSADM, DBADM USING POLICY ADMINSPOLICY COMMIT Example of auditing any access by a specific role -----------------------------------------------------------CREATE AUDIT POLICY WEBAPPPOLICY CATEGORIES EXECUTE WITH DATA STATUS BOTH ERROR TYPE AUDIT COMMIT AUDIT ROLE TELLER, ROLE CLERK USING POLICY WEBAPPPOLICY COMMIT Example of archiving a log and extracting data to a table -----------------------------------------------------------1. CALL SYSPROC.AUDIT_ARCHIVE( '/auditarchive', -2 ) CALL SYSPROC.AUDIT_DELIM_EXTRACT('', '', '/auditarchive', 'db2audit.%', '' ) cd sqllib/misc db2 -tvf db2audit.ddl Loading DB2 audit data into tables: 2. To load the AUDIT table, issue the following command: LOAD FROM audit.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.AUDIT 3. To load the CHECKING table, issue the following command: LOAD FROM checking.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE

INSERT INTO schema.CHECKING 4. To load the OBJMAINT table, issue the following command: LOAD FROM objmaint.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.OBJMAINT 5. To load the SECMAINT table, issue the following command: LOAD FROM secmaint.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.SECMAINT 6. To load the SYSADMIN table, issue the following command: LOAD FROM sysadmin.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.SYSADMIN 7. To load the VALIDATE table, issue the following command: LOAD FROM validate.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.VALIDATE 8. To load the CONTEXT table, issue the following command: LOAD FROM context.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.CONTEXT 9. To load the EXECUTE table, issue the following command: LOAD FROM execute.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.EXECUTE 10. After you finish loading the data into the tables, delete the .del files fro m the security/auditdata subdirectory of the sqllib directory. 11. When you have loaded the audit data into the tables, you are ready to select data from these tables for analysis.

DB2 Roles and Trusted Context: --------------------------------------------------------------------Roles simplify the administration and management of privileges by offering an eq uivalent capability as groups but without the same restrictions. Restrictions: There are a few restrictions in the use of roles: 1. A role cannot own database objects. 2. Permissions and roles granted to groups are not considered when you c reate the following database objects: Packages containing static SQL Views Materialized query tables (MQT) Triggers SQL Routines

When using roles, the following steps occur: 1. The security administrator creates a role, DEVELOPER: CREATE ROLE DEVELOPER

2. The database administrator (who holds DBADM authority) grants SELECT on tables SERVER, CLIENT, and TOOLS to role DEVELOPER: GRANT SELECT ON TABLE SERVER TO ROLE DEVELOPER GRANT SELECT ON TABLE CLIENT TO ROLE DEVELOPER GRANT SELECT ON TABLE TOOLS TO ROLE DEVELOPER 3. The security administrator grants the role DEVELOPER to the users in department DEV, BOB and ALICE: GRANT ROLE DEVELOPER TO USER BOB, USER ALICE 4. When BOB and ALICE leave department DEV, the security administrator revokes the role DEVELOPER from users BOB and ALICE: REVOKE ROLE DEVELOPER FROM USER BOB, USER ALICE 5. When TOM is hired in department DEV, the security administrator grants the role DEVELOPER to user TOM: GRANT ROLE DEVELOPER TO USER TOM Role hierarchies -----------------------------------------------------------------A role hierarchy is formed when one role is granted membership in another role. CREATE ROLE DOCTOR CREATE ROLE SPECIALIST CREATE ROLE SURGEON GRANT ROLE DOCTOR TO ROLE SPECIALIST GRANT ROLE SPECIALIST TO ROLE SURGEON WITH ADMIN OPTION clause: Step #1: CREATE ROLE DEVELOPER GRANT ROLE DEVELOPER TO USER BOB WITH ADMIN OPTION Step #2: GRANT ROLE DEVELOPER TO USER ALICE REVOKE ROLE DEVELOPER FROM USER ALICE Step #3: DROP ROLE DEVELOPER - FAILURE! - only a security administrator is allowed to drop the role GRANT ROLE DEVELOPER TO USER ALICE WITH ADMIN OPTION - FAILURE! - only a security administrator can grant WITH ADMIN OPTION Compare group and Role: ------------------------------------------------------------------------Group DEVELOPER_G TESTER_G SALES_G Users belonging to this group BOB ALICE, TOM ALICE, BOB

1. The security administrator creates the roles DEVELOPER, TESTER and SALES to be used instead of the groups. CREATE ROLE DEVELOPER CREATE ROLE TESTER CREATE ROLE SALES 2. The security administrator grants membership in these roles to users (setting the membership of users in groups was the system administrator s responsibility): GRANT ROLE DEVELOPER TO USER BOB GRANT ROLE TESTER TO USER ALICE, USER TOM GRANT ROLE SALES TO USER BOB, USER ALICE 3. The database administrator can grant to the roles similar privileges or authorities as were held by the groups, for example: GRANT <privilege> ON <object> TO ROLE DEVELOPER

Trusted Context & Trusted Connections: ---------------------------------------------------------------------------A trusted context is a database object that defines a trust relationship for a c onnection between the database and an external entity such as an application server. The trust relationship is based upon the following set of attributes: System authorization ID: Represents the user that establishes a database connection IP address (or domain name): Represents the host from which a database c onnection is established Data stream encryption: Represents the encryption setting (if any) for t he data communication between the database server and the database client You can establish an explicit trusted connection by making a request within an a pplication when a connection to a DB2 database is established. The security administrator must have previously defined a trusted context, using the CREATE T RUSTED CONTEXT statement, with attributes matching those of the connection you are establishing 1. The security administrator defines a trusted context in the server by using t he CREATE TRUSTED CONTEXT statement. For example: CREATE TRUSTED CONTEXT MYTCX BASED UPON CONNECTION USING SYSTEM AUTHID NEWTON ATTRIBUTES (ADDRESS '192.0.2.1') WITH USE FOR PUBLIC WITHOUT AUTHENTICATION ENABLE 2. To establish a trusted connection, use one of the following APIs in your appl ication: -----------------------------------------------------------------------Option Description Application API ------------------------------------------------------------------------

CLI/ODBC SQLConnect, SQLSetConnectAttr XA CLI/ODBC Xa_open JAVA getDB2TrustedPooledConnection,getDB2Trus tedXAConnection -----------------------------------------------------------------------3. Context Switch CREATE TRUSTED CONTEXT CTX1 BASED UPON CONNECTION USING SYSTEM AUTHID USER1 ATTRIBUTES (ADDRESS '192.0.2.1') WITH USE FOR USER2 WITH AUTHENTICATION, USER3 WITHOUT AUTHENTICATION ENABLE Application Code: int main(int argc, char *argv[]) { SQLHANDLE henv; /* environment handle */ SQLHANDLE hdbc1; /* connection handle */ char origUserid[10] = "newton"; char password[10] = "test"; char switchUserid[10] = "zurbie"; char dbName[10] = "testdb"; // Allocate the handles SQLAllocHandle( SQL_HANDLE_ENV, &henv ); SQLAllocHandle( SQL_HANDLE_DBC, &hdbc1 ); // Set the trusted connection attribute SQLSetConnectAttr( hdbc1, SQL_ATTR_USE_TRUSTED_CONTEXT,SQL_TRUE, SQL_IS_ INTEGER ); // Establish a trusted connection SQLConnect( hdbc1, dbName, SQL_NTS, origUserid, SQL_NTS,password, SQL_NT S ); //Perform some work under user ID "newton" . . . . . . . . . . . // Commit the work SQLEndTran(SQL_HANDLE_DBC, hdbc1, SQL_COMMIT); // Switch the user ID on the trusted connection SQLSetConnectAttr( hdbc1,SQL_ATTR_TRUSTED_CONTEXT_USERID, switchUserid,S QL_IS_POINTER); //Perform new work using user ID "zurbie" . . . . . . . . . //Commit the work SQLEndTranSQL_HANDLE_DBC, hdbc1, SQL_COMMIT); // Disconnect from database SQLDisconnect( hdbc1 ); return 0; } /* end of main */

Transfering Ownership: ------------------------------------------------------------------------When a database object is created, the authorization ID that was used to create the object was registered as the owner of that database object by default in the system catalogs. For example in the SYSCAT.TABLES catalog view, the OWNER colum n captures the authorization ID under which the table, view, or alias was create d. TRANSFER OWNERSHIP OF TABLE acct.employee TO USER roger PRESERVE PRIVILEGES LABEL-BASED ACCESS CONTROL (LBAC) ------------------------------------------------------------------------1. All LBAC settings or configuration are performed by the SECADM. 2. The security settings or configurations then define the security policy. 3. Only one policy can be defined per table, but each table can have its own sec urity policy. 4. The security policy is made up of at least one (but usually more) security la bel. 5. There are 3 types of security labels - Row security labels. A security label associated with a data row or re cord in a database table. - Column security labels. A security label associated with a column in a database table. - User security labels. A security label granted to a database user. 6. A security label is composed of security label components, and there are thre e types of components that you can use to build your security labels: - Sets - Arrays - Trees Implementing an LBAC Security Solution -------------------------------------------------------------------------In this case you want your: VP of Sales to be able to see all identified opportunities, as well as completed sales State Sales Executives to see only the prospective and completed sales in their state Individual sales people to see only the sales they were involved in Step 1a: Defining the Security Label CREATE SECURITY LABEL COMPONENT SALESSTATE TREE ('STATES' ROOT, 'PA' UNDER 'STATES', 'NJ' UNDER 'STATES ', 'NY' UNDER 'STATES ', 'DE' UNDER 'STATES ' ) Step 1b: Defining the Security Policy

CREATE SECURITY POLICY SALESPOLICY COMPONENTS SALESSTATE WITH DB2LBACRULES RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL Step 1c: Defining the Security Labels CREATE SECURITY LABEL SALESPOLICY.PA COMPONENT SALESSTATE 'PA' CREATE SECURITY LABEL SALESPOLICY.NJ COMPONENT SALESSTATE NJ CREATE SECURITY LABEL SALESPOLICY.NY COMPONENT SALESSTATE 'NY' CREATE SECURITY LABEL SALESPOLICY.DE COMPONENT SALESSTATE 'DE' CREATE SECURITY LABEL SALESPOLICY.STATES COMPONENT SALESSTATE 'STATES' Step 2: Creating and Protecting the SALES Table CREATE TABLE SALES (SALES_DATE DATE, SALES_PERSON VARCHAR (15), STATE CHAR (2), SALES INTEGER, MARGIN INTEGER, STATETAG DB2SECURITYLABEL) SECURITY POLICY SALESPOLICY Step 3: Insert Data -------------------------------------------------------------------------------------------------SALES_DATE SALES_PERSON STATE SALES MARGIN STATETAG -------------------------------------------------------------------------------------------------04/21/2007 SUMMER PA 9000 50 PA 03/31/2007 FROST DE 1000 40 DE 05/29/2007 SNOW NY 3000 40 NY 04/20/2007 GREEN NJ 2000 40 NJ -------------------------------------------------------------------------------------------------Step 4: Granting Security Labels to the Users using SECADM GRANT SECURITY LABEL SALESPOLICY.PA TO USER Dwaine FOR ALL ACCESS GRANT SECURITY LABEL SALESPOLICY.NY TO USER Chris FOR ALL ACCESS GRANT SECURITY LABEL SALESPOLICY.NJ TO USER Larry FOR ALL ACCESS GRANT SECURITY LABEL SALESPOLICY.DE TO USER Phil FOR ALL ACCESS

GRANT SECURITY LABEL SALESPOLICY.STATES TO USER Alyssa FOR ALL ACCESS Example 1 If Alyssa, the VP of Sales attempts to insert some data into the SALES table, it will be successful since she has read and write permission on all states. INSERT into SALES VALUES ( '06/02/2007', 'LUCAS', 'NY', 1400, 20, SECLABEL_BY_NAME('SALESPOLICY', 'NY')); If Larry tries to insert a sale for Phil, the insert will fail since Larry works in NJ, not in DE. INSERT into SALES VALUES ( '06/02/2007 , 'SMITH', 'DE, 1500, 12, SECLABEL_BY_NAME ('SALESPOLICY', 'DE )) If Larry tries to read the sales information for NY so that he can scoop s, he will not get any data. some sale

SELECT sales_date, sales_person, state, sales, margin from SALES where state='NY ' Larry tries to read all of the sales data from the SALES table by issuing the co mmand: SELECT sales_date, sales_person, region, sales, margin from SALES;

HADR Performance Tuning: ---------------------------------------------------------------------------------------HADR_SYNCMODE SYNC: Transactions on the primary database commit only after relevant logs are w ritten to disk on both the primary and the standby NEARSYNC: Transactions on the primary database commit only after the relevant lo gs are written to disk on the primary database and received into memory on the standby database ASYNC: Transactions on the primary database commit only after the relevant logs are written to local disk and sent to standby

SUPERASYNC: Transactions on the primary database commit as soon as the relevant logs are written to local disk HADR_PEER_WINDOW DB2_HADR_PEER_WAIT_LIMIT DB2_HADR_BUF_SIZE DB2_LOAD_COPY_NO_OVERRIDE