A number of ICSF callable services enable an application to create, write to, or delete a key label. By default, the user needs only READ authority to read from, create, write to, or delete a label. In some cases, however, you might want to require a higher level of authority for modifying a label than is required to merely read a label. By enabling the Granular Key Label Access control, you increase the level of access authority required to create, write to, or delete a label, while still requiring only READ authority for cryptographic functions. This way, you can give a user permission to access a key for encryption or decryption operations, while preventing that same user from changing or deleting the key record.
The following table outlines the increased access authority required when the Granular Key Label Access control is enabled.
To do this: | The level of access authority required is increased from READ to: | This impacts the following callable services: |
---|---|---|
Create a label | UPDATE | Key Record Create / Key Record Create2 PKDS Record Create |
Write to a label | CONTROL | Key Part Import / Key Part Import2 Key Record Create / Key Record Create2 Key Record Write / Key Record Write2 PKDS Record Create PKDS Record Write PKA Key Generate PKA Key Import Trusted Block Create |
Delete a label | CONTROL | Key Record Delete PKDS Record Delete Retained Key Delete |
You can enable the Granular Key Label Access control in warning or fail mode. In warning mode, the user's access authority will be checked, but only READ authority will be required. However, if a user does not have UPDATE authority when creating a label, or CONTROL authority when writing to or deleting a label, a warning will be issued and the access will be logged. Warning mode allows you to identify any users who will need to be granted increased access authority prior to moving to a stricter implementation of the policy. The stricter implementation of the policy is called fail mode. In fail mode, users who lack the increased access authority required will not be able to modify key labels. The operation will be unsuccessful, and a return code of 8 (reason code 16004) will be returned to the calling application.
It is recommended that you activate Key Store Policy for both the CKDS and the PKDS before enabling the Granular Key Label Access control. If Key Store Policy is not activated and the Granular Key Label Access control is enabled, the increased access authority checks will work only when the application passes a callable service a key label. However, if the application were to pass the callable service a key token instead of a key label, then no authorization checking will be performed. When a token is passed, ICSF will, in order to initiate a SAF authorization check, rely on an active Key Store Policy for the appropriate key store.
The following table shows the controls for enabling Granular Key Label Access in warning or fail mode. To enable one of the controls, create the appropriate profile in the XFACILIT class.
The existence of this resource profile in the XFACILIT class: | Does this: |
---|---|
CSF.CSFKEYS.AUTHORITY.LEVELS.WARN | Enables Granular Key Label Access in warning mode. In this mode, a warning will be issued if the user does not have UPDATE authority if creating a label, or CONTROL authority if writing to or deleting a label. As long as the user has READ authority, however, ICSF will allow the operation to continue. |
CSF.CSFKEYS.AUTHORITY.LEVELS.FAIL | Enables Granular Key Label Access in fail mode. In this mode, ICSF will not allow a key label to be modified if the user does not have UPDATE authority if creating a label, or CONTROL authority if writing to or deleting a label. The service returns with an error. |
RDEFINE XFACILIT CSF.CSFKEYS.AUTHORITY.LEVELS.WARN
SETROPTS RACLIST(XFACILIT) REFRESH
PERMIT RITA.RSA.TEST.* CLASS(CSFKEYS) ID(RITA) ACCESS(CONTROL)
RDEFINE XFACILIT CSF.CKDS.TOKEN.CHECK.LABEL.FAIL
RDELETE XFACILIT CSF.CKDS.TOKEN.CHECK.LABEL.WARN
SETROPTS RACLIST(XFACILIT) REFRESH