Trusted contexts in DB2

Trusted context versus trusted connection

A trusted context is the definition stored in the catalog. A trusted connection is a live attachment that matched that definition. Until CREATE TRUSTED CONTEXT is committed and the context is ENABLEd, ordinary connections from the same job remain ordinary: no role, no user switch.

Matching requires:

• SYSTEM AUTHID — the primary ID of the connector, and it must not already belong to a different trusted context
• Connection trust attributes — local JOBNAME, or remote ADDRESS / SERVAUTH, with optional ENCRYPTION minimum

If field 1 on install panel DSNTIPP is DEFER and objects to defer is ALL, trusted connections are not available. That restart setting is an operational trap after a conditional restart.

CREATE TRUSTED CONTEXT

Authorization: SECADM or SYSADM. Dynamic SQL needs DYNAMICRULES RUN. DISABLE is the default state.

1
2
3
4
5
6
7
8
CREATE TRUSTED CONTEXT CTX1
    BASED UPON CONNECTION USING SYSTEM AUTHID ADMF001
    ATTRIBUTES (ADDRESS '9.30.131.203',
                ENCRYPTION 'LOW')
    DEFAULT ROLE CTXROLE
    ENABLE
    WITH USE FOR SAM,
                 JOE ROLE ROLE1 WITH AUTHENTICATION;

IBM’s second textbook pattern is a local started task (WebSphere, CICS, a custom RRSAF server):

1
2
3
4
5
6
CREATE TRUSTED CONTEXT CTX2
     BASED UPON CONNECTION USING SYSTEM AUTHID ADMF002
     ATTRIBUTES (JOBNAME 'WASPROD')
     DEFAULT ROLE CTXROLE WITH ROLE AS OBJECT OWNER AND QUALIFIER
     ENABLE
     WITH USE FOR SALLY;

SYSTEM AUTHID sources IBM documents for local connections:

• Started task (RRSAF) — USER on the JOB statement or the RACF user of the started task
• TSO — TSO logon ID
• BATCH — USER parameter on the JOB statement

JOBNAME for those same sources is the started-task / job name, the TSO logon ID, or the job name on the JOB statement. A job name may end with * if it begins with a letter, so PAY* matches PAY1 and PAYUPD.

Trusted context attributes

ADDRESS values are IPv4 dotted decimal, IPv6 colon hex (compressed form allowed), or a domain name resolved with gethostbyname. Db2 does not validate the address at CREATE time—a typo becomes a context that never matches. ENCRYPTION values:

• NONE — no minimum (default if you omit ENCRYPTION)
• LOW — at least 64-bit DRDA encryption
• HIGH — SSL

A connection that is weaker than the minimum does not use the trusted context (IBM documents a warning). A stronger connection may still use a weaker requirement: SSL satisfies LOW and NONE.

SERVAUTH names a RACF SERVAUTH-class resource: the network access zone that contains the client IP. That lets you trust “anyone on the on-prem application VLAN” without listing every WAS address.

ALTER TRUSTED CONTEXT and DROP TRUSTED CONTEXT

1
2
3
4
5
6
7
8
9
10
11
ALTER TRUSTED CONTEXT CTX1
  ALTER ATTRIBUTES (ENCRYPTION 'HIGH')
  ADD USE FOR PAT ROLE ROLE1 WITH AUTHENTICATION
  DROP USE FOR SAM
  ENABLE;
 
ALTER TRUSTED CONTEXT CTX1
  DEFAULT ROLE CTXROLE
  WITH ROLE AS OBJECT OWNER AND QUALIFIER;
 
DROP TRUSTED CONTEXT CTX1;

ALTER can ADD ATTRIBUTES, ALTER ATTRIBUTES, or replace JOBNAME lists (JOBNAME values on ALTER ATTRIBUTES replace previous JOBNAME values). ADD USE FOR / DROP USE FOR maintain the allowed-user list, including EXTERNAL SECURITY PROFILE and PUBLIC. ENABLE and DISABLE turn matching on and off without dropping the object—use DISABLE as an emergency stop.

DROP is blocked while you still need the context; end trusted connections first. There are no GRANT privileges on the context object itself (IBM: no specific privileges on a trusted context). Authority to ALTER/DROP is the same security-administrator set as CREATE.

The new or altered definition takes effect after COMMIT. If a trusted connection is already active, some changes (default role, ROLE AS OBJECT OWNER) apply at the next reuse or new connection, not in the middle of the current unit of work.

Trusted authorization and connection trust

Connection trust is the attribute match. Trusted authorization is who may use the connection after it is trusted, and whether they must authenticate on switch:

• WITH USE FOR authorization-name — that primary ID
• EXTERNAL SECURITY PROFILE profile-name — any primary ID RACF permits to that profile
• PUBLIC — any user; they get the default role only
• WITH AUTHENTICATION — password, RACF PassTicket, or Kerberos token required (local CONNECT USER/USING for local; those tokens for remote)
• WITHOUT AUTHENTICATION — default; the system authid is already trusted, so the switch relies on the middleware

Precedence: specific authorization-name, then EXTERNAL SECURITY PROFILE, then PUBLIC. IBM’s example: JOE WITH AUTHENTICATION, profile SPROFILE WITHOUT AUTHENTICATION, PUBLIC WITH AUTHENTICATION. JOE always authenticates. SAM, who is only on SPROFILE, does not. SALLY, who is only PUBLIC, does.

If SYSTEM AUTHID itself appears on WITH USE FOR, that user’s ROLE and SECLABEL override the defaults. The TCP/IP Already Verified ZPARM can still demand a token for the system ID on remote connect even if you wrote WITHOUT AUTHENTICATION.

Trusted roles and system authorization

NO DEFAULT ROLE is the default. DEFAULT ROLE names a role that already exists. A user-specific ROLE on WITH USE FOR overrides it. Only one role is in effect; they do not stack.

WITHOUT ROLE AS OBJECT OWNER (default): created objects belong to the process authorization ID, which must hold the DDL privileges.

WITH ROLE AS OBJECT OWNER AND QUALIFIER: the context-assigned role owns new objects, is the grantor/revoker, becomes CURRENT SCHEMA, and replaces CURRENT SQLID in the SQL PATH. That is how you keep ownership off personal TSO IDs.

For ordinary SQL, role privileges are considered in addition to the user’s ID. For CREATE, GRANT, and REVOKE, Db2 uses the role if ROLE AS OBJECT OWNER is on, otherwise the ID—not a mix of both as grantor.

Optional DEFAULT SECURITY LABEL / per-user SECURITY LABEL supplies a RACF SECLABEL for multilevel security on that trusted connection. The label must be one of the SECLABEL values defined for that user in RACF.

How clients establish and switch

JDBC / Db2 Universal Java Driver APIs, CLI/ODBC keywords, and WebSphere’s “propagate client identity” property are the usual remote path. Locally, RRSAF, the DSN command processor / DB2I, and SQL CONNECT can reuse a local trusted connection. The application still has to opt in; a normal DSN SYSTEM(DB2P) from TSO does not become trusted just because a context exists for some other job name.

RACF and trusted contexts

• SYSTEM AUTHID and WITH USE FOR names are RACF user IDs (or group IDs if you use them as primary in unusual setups—normally primary IDs)
• Started-task and job USER must be allowed DSNR access like any other connector
• SERVAUTH attributes point at RACF SERVAUTH resources
• EXTERNAL SECURITY PROFILE lets RACF, not a hard-coded SQL list, decide who may switch onto the connection
• SECLABEL on the context is RACF MLS

RACF access control module profiles (MDSN*) still decide object privileges if that exit is installed. The trusted context only adds the role and the right to switch users. You still GRANT (or PERMIT) EXECUTE, SELECT, and the rest to the role or to the switched-to ID.

Explain It Like I'm Five

A trusted context is a special classroom door. The door only opens if the teacher who knocks is the expected teacher (SYSTEM AUTHID) and they knock from the expected hallway (the job name or the school’s network address). Inside, the teacher can hand a student badge to Alice without Alice remembering a second password. Alice’s badge can include a costume (a role) she is not allowed to wear on the playground. If you lock the door (DISABLE) or change the hallway address (ALTER ATTRIBUTES), the old knocks no longer count as special.

Exercises

1. Write a CREATE TRUSTED CONTEXT for started task CICSPROD, user CICSUSER, default role TELLER, enabled, usable by PUBLIC WITHOUT AUTHENTICATION.
2. Add ENCRYPTION HIGH and ADDRESS for a single WAS IP. Who can still connect without SSL?
3. ALTER the context so ALICE gets role SUPERVISOR WITH AUTHENTICATION and BOB is removed. What is the precedence if PUBLIC is also allowed?
4. Explain when you would use SERVAUTH instead of a list of ADDRESS values.
5. Why would you set WITH ROLE AS OBJECT OWNER AND QUALIFIER on a WAS trusted context that deploys DDL?