Configuring RACF for identity propagation

Use the RACF® RACMAP command to create, delete, and list a distributed identity filter. Use the RACF SETR RACLIST(IDIDMAP) command to refresh the IDIDMAP resource profile that contains the distributed identity filter. You must configure your RACF settings for identity propagation before you update clients and CICS® configuration definitions.

Before you begin

Ensure that you have the required access to update RACF profiles for your z/OS® system.

About this task

RACF uses the term distributed identity filter to describe a mapping association between a RACF user ID and one or more distributed identities. When you define the filter using the RACMAP command, you associate (or map) a distributed identity with a RACF user ID. If the distributed identity is not mapped in the RACMAP command, the default CICS user ID is not used and a security error is issued. Each distributed identity filter is stored in a general resource profile in the IDIDMAP class.

The owner of an IDIDMAP profile is the user ID of the RACMAP MAP command issuer.

When the SETR RACLIST(IDIDMAP) command is issued, the IDIDMAP class becomes active. When a distributed user is authenticated and the supported transaction is sent to the z/OS system, RACF receives the distinguished name and realm of the user as character strings of UTF-8 data. RACF has a number of restrictions as a result of UTF-8 data encoding; for example, if the distinguished name exceeds 246 bytes or the realm exceeds 252 bytes, the RACMAP MAP command fails. See the topic about restrictions for UTF-8 data values in the z/OS Security Server RACF Security Administrator's Guide.

RACF uses the distinguished name and realm to search IDIDMAP profiles for the distributed identity filter that contains the name values best matching the data. When the best matching filter is found, RACF assigns a RACF user ID.

Procedure

Create a generic profile called IRR.IDIDMAP.* in the FACILITY class in RACF.

Grant UPDATE access to your user group to enable general access to this profile.

Here is an example, using dev as the name of the user group:

RDEFINE FACILITY IRR.IDIDMAP.** OWNER(cpssing) 
PERMIT IRR.IDIDMAP.** CLASS(FACILITY) ID(dev) ACCESS(UPDATE)
SETROPTS RACLIST(FACILITY) REFRESH

You can grant specific users authority to manage the IDIDMAP class by granting CLAUTH access.
Here is an example, using usera, userb, and userc as the users that are granted access:
```
ALTUSER (usera,userb,userc) CLAUTH(IDIDMAP) 
```
Issue the following command to activate the changes:
```
SETROPTS CLASSACT(IDIDMAP) RACLIST(IDIDMAP) 
```
If you are changing RACMAP definitions on a running system, the cached copy might not map to the same user ID as the new RACMAP definition. To reset the mapping you must wait until the cached copy is deleted. The copy is deleted if the distinguished name and realm pair (the distributed user ID) is not used for the length of time that is specified in the USRDELAY SIT parameter.
For performance reasons, CICS caches distinguished names and realms so that the first requests only from a distinguished name and realm require RACF to build an ACEE using the RACMAP definitions.

Results

The distributed user information is mapped in RACF. RACF is configured to map the distributed identity to a RACF user ID.

What to do next

You are now ready to configure your IPIC or Web service connections to CICS. For more information about the RACF RACMAP and SETR RACLIST(IDIDMAP) commands, see the information about distributed identity filters in the z/OS Security Server RACF Security Administrator's Guide.