Configuring user ID mapping
You can configure the Identity Cache to specify how mappings to local z/OS
user IDs should be handled. These configuration options can be specified in
the IRR.ICTX.DEFAULTS.sysid or IRR.ICTX.DEFAULTS profile
in the LDAPBIND class.
- The USEMAP configuration option specifies whether to accept or ignore user ID mappings provided by applications. If you specify USEMAP(YES), and an application provides a valid mapping to a local z/OS user ID, it will be stored in the Identity Cache. If you specify USEMAP(NO), application-provided ID mappings will be ignored.
- The DOMAP configuration option specifies whether or not EIM services should
be used to map a user ID stored by the application in the Identity Cache to
a local z/OS user ID. If you specify DOMAP(YES), an EIM lookup operation will
be used to find the ID mapping. If a mapping is found, it will be stored in
the Identity Cache. If you specify DOMAP(NO), the Identity Cache will not
use EIM to find a mapping.
If DOMAP(YES) is used, the Identity Cache needs to be fully configured to access the EIM domain. See Configuring and setting up EIM for more information.
- The MAPREQUIRED configuration option specifies whether or not a mapping to a local z/OS user ID is required. If MAPREQUIRED(YES) is specified and no valid mapping is provided by the application or found using EIM, the application request to store information in the Identity Cache will fail. If MAPREQUIRED(NO) is specified, then valid ID mappings will, if provided by the application or found using EIM, be stored in the Identity Cache, but will not be required.
The following are the default user ID mapping settings:
- USEMAP(YES) — user ID mappings provided by applications are accepted
- DOMAP(NO) — the Identity Cache does not perform mapping itself
- MAPREQUIRED(NO) — there is no requirement for a user ID mapping to be stored with user information
The following table summarizes the combined effect of the various configuration
option settings.
| USEMAP | DOMAP | MAPREQUIRED | Effect |
|---|---|---|---|
| NO | NO | NO | The Identity Cache will not use an application provided mapping to a z/OS user ID and it will not use EIM to find a mapping. Even if an application mapping is provided, no mapping is stored. |
| NO | NO | YES | The Identity Cache will not use an application provided mapping to a z/OS user ID and it will not use EIM to find a mapping. A mapping is required, so the Identity Cache will return an error. |
| NO | YES | NO | The Identity Cache will not use an application provided mapping to a z/OS user ID. It will use EIM to find a mapping. If a mapping is found, it will be stored. If no mapping is found, the Identity Cache will not return an error. |
| NO | YES | YES | The Identity Cache will not use an application provided mapping to a z/OS user ID. It will use EIM to find a mapping. If a mapping is found, it will be stored. If no mapping is found, the Identity Cache will return an error. |
| YES | NO | NO | If an application provides a mapping to a z/OS user ID, it will be stored. The Identity Cache will not use EIM to find a mapping. If no mapping is provided, the Identity Cache will not return an error. |
| YES | NO | YES | If an application provides a mapping to a z/OS user ID, it will be stored. The Identity Cache will not use EIM to find a mapping. If no mapping is provided, the Identity Cache will return an error. |
| YES | YES | NO | If an application provides a mapping to a z/OS user ID, the Identity Cache will store it. If not, the Identity Cache will use EIM to find a mapping to store. If no mapping is provided or found, the Identity Cache will not return an error. |
| YES | YES | YES | If an application provides a mapping to a z/OS user ID, the Identity Cache will store it. If not, the Identity Cache will use EIM to find a mapping to store. If no mapping is provided or found, the Identity Cache will return an error. |
Since user ID mappings can change over time, a user ID mapping stored in the Identity Cache will expire. By default, a user ID mapping will be stored in the Identity Cache for 1 hour, but you can set this to a shorter interval using the MAPPINGTIMEOUT configuration option. The MAPPINGTIMEOUT interval is specified in seconds, and valid values range from 1 to 3600.
A copy of the current configuration settings is kept in-storage to allow
fast access to the values. The configuration settings can be defined in an
IRR.ICTX.DEFAULTS.sysid profile in the LDAPBIND class.
For example:
RDEFINE LDAPBIND IRR.ICTX.DEFAULTS.SYSA ICTX(USEMAP(NO) DOMAP(YES)
MAPREQUIRED(YES) MAPPINGTIMEOUT(1800)) EIM(LOCALREGISTRY(MyZOSRegistry))This example defines the settings for the system with a system ID of SYSA,
and establishes the following rules:
- Because USEMAP(NO) is specified, any mappings provided by the application are ignored.
- Because DOMAP(YES) is specified, the Identity Cache itself will extract mappings from EIM. Because LOCALREGISTRY(MyZOSRegistry) is specified, the Identity Cache will use the EIM registry name of MyZOSRegistry when looking for mappings in the configured EIM domain.
- Because MAPREQUIRED(YES) is specified, any requests to store user identity information are rejected if a mapping can’t be found in EIM.
- Because MAPPINGTIMEOUT(1800) is specified, the mappings to RACF user IDs that are stored in the cache can be reused for 30 minutes instead of the default 1 hour.
These same values could be stored in a profile with the name IRR.ICTX.DEFAULTS. However, be careful using this because applications on other systems that are sharing the RACF database may also default to using this same profile.
The final step to making the settings take effect is that the LDAPBIND class must be active and RACLISTed. The entire set of field values must be specified or defaulted to in the profile before the in-storage copy of the fields is updated.