Enhanced External Security for Dataquery for Datacom

Products

Datacom DATACOM - AD Datacom/AD Datacom/DB Datacom/Server

Issue/Introduction

This KD describes Enhanced External Security for Dataquery for Datacom.

Environment

Release: Datacom

Resolution

In preparing this article, it is assumed that the reader has a basic understanding of the external security feature of Datacom/DB Database. Also, the discussion and examples make no assumptions regarding which external security product is in use. This article is not meant to be External Security 101.

First, a brief review of the genesis of paths in the Datacom external security implementation. When the external security feature was first introduced, a user ID had the same access rights to a table regardless of the means of access. In other words, a user accessing a table using navigational requests had the same access rights using SQL. (For the purposes of this article, navigational includes record-at-a-time (RAAT) and set-at-a-time (SAAT) commands.) It was determined that this implementation was insufficient in many environments.

To provide a finer degree of granularity, the concept of "paths" was introduced in Datacom/DB r9. The concept of paths was implemented by adding a new Table Class called DXTABLE in addition to the existing DTTABLE. Also, the concept of "levels of security" was introduced using a pair of new DTSYSTEM resources: LEVEL01 and LEVEL02. LEVEL01 provided for only the single table class, DTTABLE, which was the original implementation. LEVEL02 provides two security paths, one for navigational and one for SQL. Thus, a user could have different access rights to a table depending on the type of commands being used.

Further experience indicated that an even finer degree of granularity was required bringing about the introduction of four additional table classes: DCTABLE, DFTABLE, DRTABLE, and DSTABLE plus a new DTSYSTEM resource level, LEVEL03. At this level, a single user could have up to six different sets of access rights to the same table depending on the type of commands being used and the type of application being used. The three application types are: distributed (using Datacom Server Option), CICS, or any other types (such as batch). For each application type, the user can have different access rights for navigational and SQL. The combination of application type and command type is referred to as a "path".

To assign meaning to a particular Table Class/Command combination, the SECURITY Multi-User Startup Option was expanded. This expansion allows you to specify which Table Class is to be used to store the access rights for a particular path or even that no security is to be in effect for a particular path. This was accomplished by assigning a "path code" to a table class. For example: DBDCSCI indicates that the DCTABLE Table Class (the "DC" in the code) is to be used for all SQL requests issued from CICS (the "SCI" in the code). At LEVEL03, there are six "path codes" so that each Table Class could possibly be assigned to a different path. (Note that the "DB" in the code is a constant.) The six path codes at LEVEL03 are:

Path Code	Application	Command Type
RCI	CICS	Navigational
RSR	Server	Navigational
RAT	Other	Navigational
SCI	CICS	SQL
SSR	Server	SQL
SQL	Other	SQL

LEVEL04 implements External Security for SQL Views. This brings us to LEVEL05. Again, experience with External Security at LEVEL03 and LEVEL04 indicated that there was a need for separate security rights for requests coming from Dataquery for Datacom depending on whether the requests came through CICS or batch Dataquery. An example of this requirement would be an Dataquery user who needs update access rights to a table when using a given CICS application, but in this scenario the user would not need to have update access rights (or possibly any access rights) when using Dataquery under CICS. Another example is a user who needs to be able to run batch Dataquery against a table to provide certain statistics but cannot be allowed to run ad hoc queries against the table under CICS (online Dataquery).

LEVEL05 is available in r11 of Datacom/DB and Dataquery. It introduces four additional Table Classes and four path codes. This brings the potential number of individual paths that can be separately secured to ten. The additional Table Classes are DGTABLE, DHTABLE, DPTABLE, and DQTABLE. The new path codes are:

Path Code Application Command Type RAQ Batch Dataquery Navigational RCQ CICS Dataquery Navigational SCQ CICS Dataquery SQL SQQ Batch Dataquery SQL

Path Code	Application	Command Type
RAQ	Batch Dataquery	Navigational
RCQ	CICS Dataquery	Navigational
SCQ	CICS Dataquery	SQL
SQQ	Batch Dataquery	SQL

Assuming a picture is worth a thousand words, let's pretty it up:

Now, let's use an example to demonstrate how the Table Classes and path codes can be used to provide granular security. For our example, we will assume a site that has tables that are accessible through CICS (using both Dataquery and user applications), batch (also using both Dataquery and user applications) and distributed access (using Datacom Server). Under CICS, users need update access rights when using vendor written or in-house applications, but we do not want to allow update using Dataquery. In batch, we want to allow certain users limited Dataquery update access using navigational commands, but not SQL. In addition, users need the same access rights in batch as in CICS for our applications. For distributed access, we want to allow the same SQL access rights as the users have for Dataquery under CICS.

Now, let's look at the ten access paths and see which ones require separate access rights:

	Path	Requires separate access rights
1	RAQ:	Yes (Need to allow certain users limited update in batch Dataquery)
2	RAT:	Yes (Need to allow applications to update tables)
3	RCI:	No (Can share Table Class with RAT path)
4	RCQ:	Yes (Need to disallow update rights in Dataquery)
5	RSR:	Yes (Need to disallow any navigational request through Datacom Server)
6	SCI:	No (Can share Table Class with RAT path)
7	SCQ:	No (Can share Table Class with RCQ path)
8	SQL:	No (Can share Table Class with RAT path)
9	SQQ:	No (Can share Table Class with RCQ path)
10	SSR	No (Can share Table Class with RCQ path)

The four "Yes" answers indicate that we need four Table Classes. Each Table Class defines a separate set of access rights. Since we can choose any of the ten Table Classes, let's define our Table Classes as follows:

DTTABLE: Access rights for users running our applications (batch or online)
DQTABLE: Access rights for batch Dataquery
DRTABLE: Access rights for online Dataquery
DSTABLE: Access rights for Datacom Server navigational.

Given these definitions, the SECURITY Multi-User Startup Option would appear as follows:

SECURITY DBDTRAT,DBDTRCI,DBDTSCI,DBDTSQL,DBDQRAQ
SECURITY DBDRRCQ,DBDRSCQ,DBDRSQQ,DBDRSSR,DBDSRSR

Looking at this implementation from the opposite point of view, we can determine where to look in the security system for access rights by looking at the path code options. For example, if a user attempts issuing a SQL command in online Dataquery and gets a message indicating a security violation, we know we must see that there are access rights defined for this user to the DRTABLE Table Class. We know this from the DBDRSCQ path option. SCQ indicates online Dataquery SQL commands and DR indicates these rights are contained in the DRTABLE Table Class.

To complete the implementation, we must define the path code options as resources of the class DTSYSTEM. Assuming a CXXname of "SAMPLE", our DTSYSTEM resources would appear as follows:

SAMPLE.DBDTRAT
SAMPLE.DBDTRCI
SAMPLE.DBDTSCI
SAMPLE.DBDTSQL
SAMPLE.DBDQRAQ
SAMPLE.DBDRRCQ
SAMPLE.DBDRSCQ
SAMPLE.DBDRSQQ
SAMPLE.DBDRSSR
SAMPLE.DBDSRSR

To validate these resources to external security, the user ID which is associated with the Multi-User startup in the security system must be denied access to each of the resources. If any of them are not defined or the user is not denied access to them, MUF issues a message and does not enable.

Updating our picture to match our implementation we see:

As you can see, there are many ways to use the path concept. It is a very dynamic and useful feature of external security in Datacom/DB. The addition of the new paths to support Dataquery access has made it possible to limit or open access to tables to whatever degree makes sense in your environment.