Setting up authorization to ICSF callable services

When the RemoteCryptoPKCS#11 or RemoteCryptoCCA extended operations are used, the authenticated user must have the appropriate access to call the underlying ICSF callable service. Before using the RemoteCryptoPKCS#11 or RemoteCryptoCCA extended operation, the authenticated user must resolve to a SAF identity, which is then granted authorization to the underlying ICSF callable services. The following binds in the z/OS® LDAP server can resolve to a SAF identity:

Simple bind to the SDBM backend. See SDBM authorization for more information.
LDBM or TDBM native authentication bind. Native authentication allows the use of an LDBM or TDBM entry but the password or password phrase is stored in SAF. See Native authentication for more information.
Kerberos (GSSAPI) bind. See Kerberos authentication for more information.
SASL EXTERNAL certificate bind where the certificate is mapped to a SAF user. The sslMapCertificate configuration option must be set to fail the SASL EXTERNAL bind request if the user cannot be mapped to a SAF or RACF® user. See Setting up for SSL/TLS for more information about mapping certificates to users.

The security administrator must decide the authorization that each authenticated user must have when accessing the remote crypto plug-in and using the RemoteCryptoPKCS#11 or RemoteCryptoCCA extended operation, which calls the underlying ICSF callable service. See Table 1 for the ICSF callable services that are supported by the remote crypto plug-in. If the CSFSERV class is active on your system, ICSF performs access control checks on the underlying callable services. To provide users access to all supported ICSF callable services other than those protected by discrete profiles, the security administrator can define a generic profile in the CSFSERV class and permit users READ access to the generic profile. For example:

 RDEFINE CSFSERV CSF* UACC(NONE)
	PERMIT CSF* CLASS(CSFSERV) ACCESS(READ) ID(USER1)
	SETROPTS CLASSACT(CSFSERV)
	SETROPTS RACLIST(CSFSERV) REFRESH

Additionally, specific ICSF callable services can be protected individually with discrete profiles, regardless of the presence of a generic profile. For example, to provide USER1 access specifically to the CSFPTRC callable service, the security administrator could issue the following commands:

	RDEFINE CSFSERV CSF1TRC UACC(NONE)
	PERMIT CSF1TRC CLASS(CSFSERV) ACCESS(READ) ID(USER1)
	SETROPTS CLASSACT(CSFSERV)
	SETROPTS RACLIST(CSFSERV) REFRESH

See z/OS Cryptographic Services ICSF Writing PKCS #11 Applications and z/OS Security Server RACF Security Administrator's Guide for more information about the supported CSFSERV class and granting authorization.