RACF and DB2 security integration

Two layers of RACF integration

Think of Db2 security as a front door and a filing cabinet. RACF almost always owns the front door. The filing cabinet (table, package, and plan privileges) may still be owned by Db2 GRANT and REVOKE until your shop installs extra RACF support.

• Identification and authentication — RACF verifies the user ID and password, PassTicket, or certificate. The verified ID becomes the primary authorization ID of the Db2 process.
• Group connections — RACF groups connected to that user become secondary authorization IDs (through the connection exit, commonly DSN3@ATH / DSN3SATH). Privileges granted to a group then apply to every connected user.
• Subsystem access — class DSNR decides whether that ID may attach to this Db2 subsystem at all.
• Object authorization (optional) — if you replace the default access control exit, RACF profiles can decide SELECT, BIND, EXECUTE, and administrative authorities instead of (or together with) catalog tables.

That last layer is what IBM calls the RACF access control module. It is powerful and common in shops that want one security team, one set of generic profiles, and rules that exist before a table is created. It is not automatic just because users log on with RACF.

RACF at the front door: class DSNR

Before SQL runs, the requester must be allowed into the subsystem. Profiles in class DSNR typically look like ssid.resource:

• ssid.BATCH — TSO and batch attachments (including SPUFI, DSN command processor, and many utilities)
• ssid.DIST — distributed (DDF) connections
• ssid.MASS — IMS
• ssid.SASS — CICS

If RACF says no here, Db2 never gets as far as checking SELECT on HR.EMPLOYEE. Remote clients can be required to pass several RACF checks (network, APPL, and DSNR) before DDF accepts them. That is why a “Db2 password error” is often a RACF or AT-TLS problem, not a GRANT problem.

1
2
3
RDEFINE DSNR DB2P.BATCH UACC(NONE)
PERMIT DB2P.BATCH CLASS(DSNR) ID(PAYGROUP) ACCESS(READ)
SETROPTS RACLIST(DSNR) REFRESH

Exact profile names follow your naming standard and data sharing group name. The idea is always the same: RACF answers “may this ID use this attachment?” before Db2 answers “may this ID run this SQL?”

Secondary IDs from RACF groups

Native Db2 GRANT is often issued to a RACF group, not to every person. When PAY01 logs on and RACF lists group PAYROLL among the connected groups, Db2 can treat PAYROLL as a secondary authorization ID. Then:

1
GRANT SELECT ON TABLE HR.EMPLOYEE TO PAYROLL;

PAY01 can SELECT without a personal GRANT. Disconnect PAY01 from the group and the access disappears without a REVOKE. That pattern is the everyday meaning of “RACF integration” even in shops that never installed the access control module.

CURRENT SQLID can usually be set to the primary ID or to a secondary ID the process holds. That is how a developer in several RACF groups picks which identity dynamic SQL should use for unqualified objects and certain privilege checks.

Native Db2 authorization (the default filing cabinet)

By default, Db2 stores privileges in the catalog (SYSIBM.SYSTABAUTH, SYSCOLAUTH, SYSPLANAUTH, SYSPACKAUTH, and related tables). GRANT and REVOKE change those rows. At run time Db2 reads them (and caches results) to allow or deny a statement.

The default routine at exit DSNX@XAC tells Db2 that no external authorization program is installed. Db2 then uses native checking and does not keep calling the exit. Source for that default is member DSNXSXAC in prefix.SDSNSAMP; the load module lives in SDSNLOAD / SDSNEXIT depending on install.

Native authorization is simple to teach: GRANT EXECUTE ON PLAN PAYPLAN TO TELLER. It also has well-known pain points. Cascading REVOKE can surprise you. You cannot define a rule before the object exists. Dropping and recreating a table can lose the old GRANTs. Those are the problems RACF profiles are designed to avoid.

The RACF access control module

IBM ships sample assembler DSNXRXAC. You copy it, optionally change SET symbols for class naming, then assemble and link it as DSNX@XAC into the APF-authorized exit library, usually by customizing install job DSNTIJEX. After Db2 restarts, the module is called:

• At startup — load profiles into storage; the reason code tells Db2 how to treat later failures
• On a privilege check — instead of (or before) reading catalog auth tables for that privilege
• At shutdown — cleanup

IBM documents these benefits of letting RACF perform Db2 authorization checking:

• Single point of control — security administrators use RACF commands and reports they already know
• Define rules before the object exists — generic profiles can wait for CREATE TABLE
• Rules survive DROP — deleting a table does not delete the RACF profile
• One profile, many objects — generics, grouping classes, and member classes
• No cascading revoke of dependent privileges when a RACF permit is removed
• Validate the user ID as part of the object check

How privileges map to RACF

The module simulates Db2 checking with RACF resources:

• Object type → RACF class name (MDSNTB for tables, MDSNPK for packages)
• Privilege → last qualifier of the resource name (SELECT, BIND, EXECUTE)
• Administrative authority → class DSNADM
• Security rule → a RACF profile covering that resource

Default IBM class names use an M member class and a G grouping class. In multiple-subsystem scope, class names are shared (MDSNPK) and the subsystem or group attach name is the first qualifier of the profile. In single-subsystem scope, the subsystem name is baked into the class name instead. Assembler SET options &CLASSOPT, &CLASSNMT, and &CHAROPT control that naming. Change them only with your RACF administrator; mismatched names mean every check fails closed or open in surprising ways.

1
2
3
4
5
6
7
8
9
* Table SELECT in multiple-subsystem scope (illustrative)
RDEFINE MDSNTB DB2P.HR.EMPLOYEE.SELECT UACC(NONE)
PERMIT DB2P.HR.EMPLOYEE.SELECT CLASS(MDSNTB) ID(PAYROLL) ACCESS(READ)
 
* Package EXECUTE
RDEFINE MDSNPK DB2P.PAYROLL.PAY01.EXECUTE UACC(NONE)
PERMIT DB2P.PAYROLL.PAY01.EXECUTE CLASS(MDSNPK) ID(TELLERS) ACCESS(READ)
 
SETROPTS CLASSACT(MDSNTB MDSNPK DSNADM) RACLIST(MDSNTB MDSNPK DSNADM) REFRESH

When the module is not called

Even after you install DSNXRXAC, Db2 still skips the exit in documented cases:

• Installation SYSADM or installation SYSOPR when that authority is enough — those checks stay inside Db2
• USE PROTECTION = NO on install panel DSNTIPP — Db2 security disabled
• Cached authorization from an earlier successful check
• A prior exit call told Db2 not to call again
• GRANT statements that maintain Db2 catalog privileges — they are not the same path as a runtime privilege check

BIND with a different OWNER is a subtle case. The primary ID may be checked in RACF while static SQL authorization also considers the package owner. If only the binder holds installation SYSADM, later checks for the owner still go to RACF. Read IBM’s “when the module is bypassed” list before you assume SYSADM on a TSO ID blinds RACF for every nested check.

Multilevel security and trusted contexts

RACF SECLABEL values support multilevel security (label-based / mandatory access control) on tables that have a security label column. That model is separate from the RACF access control module, and it is mutually exclusive with row access control (row permissions) on the same table. Column masks can still be used with a security-label column.

Trusted contexts can name a RACF EXTERNAL SECURITY PROFILE so that anyone permitted to that RACF profile may reuse a trusted connection, optionally with a Db2 role and a SECLABEL. SERVAUTH zones can also appear as trusted-context ADDRESS alternatives. Those features are covered on the trusted contexts page; the takeaway here is that RACF identity, RACF groups, RACF profiles, and RACF labels all show up inside SQL security objects.

A practical way to think about your shop

Ask three questions and write down the answers. They tell you which diagrams in this tutorial apply.

• Who authenticates? Almost always RACF (or ACF2/Top Secret emulating the same interfaces).
• Who may attach? DSNR (and related APPL/network profiles) — still RACF.
• Who may SELECT / BIND / EXECUTE? Either SYSIBM catalog tables (native GRANT) or RACF object classes via DSNX@XAC, plus row permissions and column masks on top of either model.

Mixing models without a written standard is how you get “I granted SELECT but RACF still says no,” or the reverse. Installation SYSADM can still outrank RACF for some checks, which is why auditors care who is listed as install SYSADM.

Explain It Like I'm Five

RACF is the school office that checks your name badge at the front gate. Db2 is the classroom with the grade book. The office always decides whether you may walk onto campus (that is DSNR). Inside the classroom, either the teacher’s grade book (GRANT in the Db2 catalog) or a second office list (RACF profiles through a special door called DSNX@XAC) decides whether you may open a particular locker. Your club membership card (a RACF group) can get you into lockers that were opened for the whole club, not just for you.

Exercises

1. At your site, find whether SDSNEXIT contains the default DSNX@XAC or the RACF module built from DSNXRXAC. Ask which job (often DSNTIJEX) last assembled it.
2. List the DSNR profiles for your subsystem and match each suffix (BATCH, DIST, MASS, SASS) to an attachment.
3. Explain why GRANT SELECT TO a RACF group works even when the RACF access control module is not installed.
4. Write the RACF resource name you would expect for EXECUTE on package PAYROLL.PAY01 in subsystem DB2P using default multiple-subsystem class names.
5. Name two situations in which Db2 will not call the RACF access control module even if it is installed.