Steps for SAF-protecting ICSF services and CCA keys

This procedure describes one approach for SAF-protecting services and CCA keys:

Decide whether you will protect keys, services, or both. You can select which keys and services to protect.
You may want to organize the users who need access to ICSF keys and services into groups. To do this, obtain a list of the user IDs of users who need to use ICSF keys and services. If batch jobs or started tasks need to use ICSF, obtain the user IDs under which they will run.
Group any of the user IDs together if they require access to the same keys and services. For example, you might want to set up groups as follows:
- Users who work with MAC-related callable services.
- Users who work with a particular MAC or a particular PIN.
- Users who call applications to dynamically update the CKDS or PKDS.
- Users who work with digital signing callable services.
- Users who work with PKCS #11 applications.
Usually, all users of ICSF should have access to keys and services by virtue of their membership in one of these SAF groups, rather than specific users. This is because SAF maintains the access lists in in-storage profiles. When the in-storage profiles are created or changed, the in-storage profiles must be refreshed. (Merely changing them in the SAF database is not sufficient. This is analogous to the in-storage CKDS maintained by ICSF.) To refresh the in-storage SAF profiles, the security administrator must use the SETROPTS command:
```
    SETROPTS RACLIST(CSFKEYS) REFRESH
    SETROPTS RACLIST(CSFSERV) REFRESH
```
If you place SAF groups in the access lists of the SAF profiles, you can change a user's access to the protected services and keys by adding or removing the user from the groups. Ask your security administrator to create the SAF groups.

You should also ask your security administrator to connect you to these groups with CONNECT group authority. This permits you to connect and remove users from the groups.
For example, the security administrator could issue these commands:
```
    ADDGROUP groupid
    CONNECT  your-userid  GROUP(groupid)  AUTHORITY(CONNECT)
```
With CONNECT group authority, you are able to connect other users to the groups:
```
    CONNECT  other-userid  GROUP(groupid)
```
With CONNECT group authority, you are also able to remove users from the groups:
```
    REMOVE  other-userid  GROUP(groupid)
```
Ask your security administrator for the authority to create and maintain profiles in the CSFKEYS and CSFSERV general resource classes. Usually, this is done by assigning a user the CLAUTH (class authority) attribute in the specified classes. For example, the security administrator can issue this command:
```
    ALTUSER  your-userid  CLAUTH(CSFKEYS CSFSERV)
```
If you want to use generic profiles that contain characters such as * and %, ask your security administrator to activate generic profile checking in the CSFKEYS and CSFSERV classes:
```
    SETROPTS  GENERIC(CSFKEYS CSFSERV)
```
Note: Using generic profiles has several advantages. Using generic profiles, you can reduce the number of profiles that you need to maintain. You can also create a "top" generic profile that can be used to protect all keys and services that are not protected by a more specific profile.
Define profiles in the CSFKEYS and CSFSERV classes. For further instructions, see Setting up profiles in the CSFKEYS general resource class and Setting up profiles in the CSFSERV general resource class.
Activate logging for CSFSERV using these commands:
- ALTUSER userid UAUDIT - audits a userid.
- RALTER class-name profile-name AUDIT(audit-attempt[(audit-access-level)]) - used by the profile owner.
  RALTER class-name profile-name GLOBALAUDIT(access-attempt[(audit-access-level)]) - used by a user with AUDITOR authority to set up profiles.
- SETROPTS CLASSACT(CSFSERV) RACLIST(CSFSERV)
  SETR LOGOPTIONS(CSFSERV(....))
For more information on RACF RDEFINE, RALTER, and SETR, see the z/OS Security Server RACF Command Language Reference.