Translating inbound IDs
Duplication of authorization IDs on different logical units (LUs) is a serious security exposure. For tighter security, make sure that each of the authorization IDs has the same meaning throughout your entire network.
About this task
Suppose that the ID DBADM1 is known to the local Db2 and has DBADM authority over certain databases there; suppose also that the same ID exists in some remote LU. If an attachment request comes in from DBADM1, and if nothing is done to alter the ID, the wrong user can exercise privileges of DBADM1 in the local Db2. The way to protect against that exposure is to translate the remote ID into a different ID before the attachment request is accepted.
You must be prepared to translate the IDs of plan owners, package owners, and the primary IDs of processes that make remote requests. Do not plan to translate all IDs in the connection exit routine—the routine does not receive plan and package owner IDs.
If you have decided to manage inbound IDs through Db2, you can translate an inbound ID to some other value. Within Db2, you grant privileges and authorities only to the translated value. The translation
is not affected by anything you do in your connection or sign-on exit routine. The output of the translation becomes the input to your sign-on exit routine.
The examples in the following table shows the possibilities for translation and how to control translation by SYSIBM.USERNAMES. You can use entries to allow requests only from particular LUs or particular IDs, or from combinations of an ID and an LU. You can also translate any incoming ID to another value.
| Row | TYPE | AUTHID | LINKNAME | NEWAUTHID |
|---|---|---|---|---|
| 1 | I | blank | LUSNFRAN | blank |
| 2 | I | BETTY | LUSNFRAN | ELIZA |
| 3 | I | CHARLES | blank | CHUCK |
| 4 | I | ALBERT | LUDALLAS | blank |
| 5 | I | BETTY | blank | blank |
The following table shows the search order of the SYSIBM.USERNAMES table.
| AUTHID | LINKNAME | Result |
|---|---|---|
| Name | Name | If NEWAUTHID is specified, AUTHID is translated to NEWAUTHID for the specified LINKNAME. |
| Name | Blank | If NEWAUTHID is specified, AUTHID is translated to NEWAUTHID for all LINKNAMEs. |
| Blank | Name | If NEWAUTHID is specified, it is substituted for AUTHID for the specified LINKNAME. |
| Blank | Blank | Unavailable resource message (SQLCODE -904) is returned. |
Db2 searches SYSIBM.USERNAMES to determine how to translate for each of the requests that are listed in the following table.
| Request | How Db2 translates request |
|---|---|
| ALBERT requests from LUDALLAS | Db2 searches for an entry for AUTHID=ALBERT and LINKNAME=LUDALLAS. Db2 finds one in row 4, so the request is accepted. The value of NEWAUTHID in that row is blank, so ALBERT is left unchanged. |
| BETTY requests from LUDALLAS | Db2 searches for an entry for AUTHID=BETTY and LINKNAME=LUDALLAS; none exists. Db2 then searches for AUTHID=BETTY and LINKNAME=blank. It finds that entry in row 5, so the request is accepted. The value of NEWAUTHID in that row is blank, so BETTY is left unchanged. |
| CHARLES requests from LUDALLAS | Db2 searches for AUTHID=CHARLES and LINKNAME=LUDALLAS; no such entry exists. Db2 then searches for AUTHID=CHARLES and LINKNAME=blank. The search ends at row 3; the request is accepted. The value of NEWAUTHID in that row is CHUCK, so CHARLES is translated to CHUCK. |
| ALBERT requests from LUSNFRAN | Db2 searches for AUTHID=ALBERT and LINKNAME=LUSNFRAN; no such entry exists. Db2 then searches for AUTHID=ALBERT and LINKNAME=blank; again no entry exists. Finally, Db2 searches for AUTHID=blank and LINKNAME=LUSNFRAN, finds that entry in row 1, and the request is accepted. The value of NEWAUTHID in that row is blank, so ALBERT is left unchanged. |
| BETTY requests from LUSNFRAN | Db2 finds row 2, and BETTY is translated to ELIZA. |
| CHARLES requests from LUSNFRAN | Db2 finds row 3 before row 1; CHARLES is translated to CHUCK. |
| WILBUR requests from LUSNFRAN | No provision is made for WILBUR, but row 1 of the SYSIBM.USERNAMES table allows any ID to make a request from LUSNFRAN and to pass without translation. The acceptance level for LUSNFRAN is already verified, so WILBUR can pass without a password check by RACF®. After accessing Db2, WILBUR can use only the privileges that are granted to WILBUR and to PUBLIC (for DRDA access). |
| WILBUR requests from LUDALLAS | Because the acceptance level for LUDALLAS is verifyas recorded in the SYSIBM.LUNAMES table, WILBUR must be known to the local RACF. Db2 searches in succession for one of the combinations WILBUR/LUDALLAS, WILBUR/blank, or blank/LUDALLAS. None of those is in the table, so the request is rejected. The absence of a row permitting WILBUR to request from LUDALLAS imposes a come-fromcheck: WILBUR can attach from some locations (LUSNFRAN), and some IDs (ALBERT, BETTY, and CHARLES) can attach from LUDALLAS, but WILBUR cannot attach if coming from LUDALLAS. |
In the process of accepting remote attachment requests, any step that calls RACF is likely to have a relatively high performance cost. To trade some of that cost for a somewhat greater security exposure, have RACF check the identity of the other LU just once. Then trust the partner LU, translating the inbound IDs and not requiring or using passwords. In this case, no calls are made to RACF from within Db2; the penalty is only that you make the partner LU responsible for verifying IDs.
If you update tables in the CDB while the distributed data facility is running, the changes might not take effect immediately. If incoming authorization IDs are managed through Db2 and if the ICSF is installed and properly configured, you can use the DSNLEUSR stored procedure to encrypt translated authorization IDs and store them in the NEWAUTHID column of the SYSIBM.USERNAMES table. Db2 decrypts the translated authorization IDs during connection processing.