Enhanced External Security for Advantage CA-Dataquery for CA-Datacom

Document ID : KB000055924
Last Modified Date : 14/02/2018
Show Technical Document Details

Summary: 

Enhanced External Security for Advantage CA-Dataquery for CA-Datacom. 

 

Instructions: 

In preparing this article, it is assumed that the reader has a basic understanding of the external security feature of Advantage CA-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 Advantage CA-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 Advantage CA-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 Advantage CA-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 CodeApplicationCommand Type
RCICICSNavigational
RSRServerNavigational
RATOtherNavigational
SCICICSSQL
SSRServerSQL
SQLOtherSQL

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 Advantage CA-Dataquery for CA-Datacom depending on whether the requests came through CICS or batch Advantage CA-Dataquery. An example of this requirement would be an Advantage CA-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 Advantage CA-Dataquery under CICS. Another example is a user who needs to be able to run batch Advantage CA-Dataquery against a table to provide certain statistics but cannot be allowed to run ad hoc queries against the table under CICS (online Advantage CA-Dataquery).

LEVEL05 is available in r11 of Advantage CA-Datacom/DB and Advantage CA-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 CA-Dataquery Navigational RCQ CICS CA-Dataquery Navigational SCQ CICS CA-Dataquery SQL SQQ Batch CA-Dataquery SQL

Path CodeApplicationCommand Type
RAQBatch CA-DataqueryNavigational
RCQCICS CA-DataqueryNavigational
SCQCICS CA-DataquerySQL
SQQBatch CA-DataquerySQL

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

imga

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 Advantage CA-Dataquery and user applications), batch (also using both Advantage CA-Dataquery and user applications) and distributed access (using Advantage CA-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 Advantage CA-Dataquery. In batch, we want to allow certain users limited Advantage CA-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 Advantage CA-Dataquery under CICS.

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

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

  1. DTTABLE:    Access rights for users running our applications (batch or online)
  2. DQTABLE:   Access rights for batch CA-Dataquery
  3. DRTABLE:   Access rights for online CA-Dataquery
  4. DSTABLE:   Access rights for CA-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 Advantage CA-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 CA-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:

  1. SAMPLE.DBDTRAT
  2. SAMPLE.DBDTRCI
  3. SAMPLE.DBDTSCI
  4. SAMPLE.DBDTSQL
  5. SAMPLE.DBDQRAQ
  6. SAMPLE.DBDRRCQ
  7. SAMPLE.DBDRSCQ
  8. SAMPLE.DBDRSQQ
  9. SAMPLE.DBDRSSR
  10. 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:

imgb

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 Advantage CA-Datacom/DB. The addition of the new paths to support Advantage CA-Dataquery access has made it possible to limit or open access to tables to whatever degree makes sense in your environment.