Identity Token Authorization Configuration - Identity Token Authorization Configuration - Call-Level Interface Version 2

Teradata® Call-Level Interface Version 2 Reference for Workstation-Attached Systems - 20.00

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
Lake
VMware
Product
Call-Level Interface Version 2
Release Number
20.00
Published
January 2024
Language
English (United States)
Last Update
2024-05-14
dita:mapPath
bmn1691484839905.ditamap
dita:ditavalPath
obe1474387269547.ditaval
dita:id
fvz1470444150352
Product Category
Teradata Tools and Utilities

The permission model employed by Identity Token Support is driven by the existence of the RACF FACILITY class profiles named:

  • TERADATA.TTU.RACFJWT

We nickname this profile as the “generic resource profile.” If this generic resource profile does not exist, then the permission model will be any to any. Otherwise, the model will be either one to one or one to many.

There are additional profiles in the following classes which provide authorization filters for Identity Token (JWT) generation.

  • FACILITY Class
  • PTKTDATA Class

The PTKTDATA class will have one or more profiles with the following name pattern:

  • IRRPTAUTH.RACFJWT.<user-filter>

This IRRPTAUTH profile determines whether a user (that meets <user-filter> criteria) can have a PassTicket generated for them.

Users who have UPDATE permissions to the IRRPTAUTH profile can generate PassTickets on behalf of the users within the <user-filter> criteria.

The FACILITY class will have zero or more profiles with the following name pattern:

  • TERADATA.TTU.RACFJWT.<userid>

We nickname these profiles as “discrete resource profiles.”

In the following sections we describe configuration details for each permission model. We will assume there is a RACF group named JWTGRP which consists of all users that are submitting jobs which generate JWT’s and all users which are subjects of those JWT’s.

Any to Any

All users in the JWTGRP should fall under a IRRPTAUTH profile. Consider the following:

  • RDEFINE PTKTDATA IRRPTAUTH.RACFJWT.*

All users in the JWTGRP need update access to the IRRPTAUTH profile. Consider the following:

  • PERMIT IRRPTAUTH.RACFJWT.* CLASS(PTKTDATA) - ID(JWTGRP) ACC(UPDATE)

The generic resource profile, TERADATA.TTU.RACFJWT, should not exist.

One to One

All users in the JWTGRP should fall under a IRRPTAUTH profile. Consider the following:

  • RDEFINE PTKTDATA IRRPTAUTH.RACFJWT.*

All users in the JWTGRP need update access to the IRRPTAUTH profile. Consider the following:

  • PERMIT IRRPTAUTH.RACFJWT.* CLASS(PTKTDATA) - ID(JWTGRP) ACC(UPDATE)

The generic resource profile, TERADATA.TTU.RACFJWT, should exist. Consider the following:

  • RDEFINE FACILITY TERADATA.TTU.RACFJWT UACC(READ)

One to Many

All users in the JWTGRP should fall under a IRRPTAUTH profile. Consider the following:

  • RDEFINE PTKTDATA IRRPTAUTH.RACFJWT.*

All users in the JWTGRP need update access to the IRRPTAUTH profile. Consider the following:

  • PERMIT IRRPTAUTH.RACFJWT.* CLASS(PTKTDATA) - ID(JWTGRP) ACC(UPDATE)

The generic resource profile, TERADATA.TTU.RACFJWT, should exist. Consider the following:

  • RDEFINE FACILITY TERADATA.TTU.RACFJWT UACC(READ)

For each user that is the subject of a JWT generated by a different user, a discrete profile should exist. In this example we want USER1 to be able to generate a JWT for USER2. Consider the following:

  • RDEFINE FACILITY TERADATA.TTU.RACFJWT.USER2 UACC(NONE)

For each user that should be able to generate a JWT for USER2, they should have read permissions to that discrete profile. Consider the following:

  • PERMIT TERADATA.TTU.RACFJWT.USER2 CLASS(FACILITY) - ID(USER1) ACC(READ)