Defining delegated resources

Some applications and daemons initiate requests that require access to resources to which the client who invoked the daemon might not otherwise need access. For example, the FTP daemon (FTPD) shipped with z/OS® Communication Server requires access to sensitive ICSF resources that the FTP client does not. Generally, you must authorize the client user IDs to access resources that are needed by the daemon. However, if instructed by the documentation for the application or daemon, such as the FTP daemon, you can define a particular resource as a delegated resource and authorize it for use by the daemon's user ID rather than by the client user IDs.

Delegated resources are general resources that are eligible to be accessed by specially programmed applications that request RACF® to check the application, or daemon's, authority for a resource when the client's authority is insufficient. Applications programmed in this way, such as the FTP daemon, are said to contain support for nested ACEEs because the identity of the application or daemon is said to be nested beneath the identity of the client for authorization purposes.

You indicate that a resource is a delegated resource by adding the text string RACF-DELEGATED to the APPLDATA field of the profile protecting the resource. The RACF-DELEGATED text string will always be translated to upper case by the RALTER or RDEFINE commands.

The RACF-DELEGATED text string can appear anywhere within the APPLDATA field, allowing for the existence of other information already in the field, or for new information that might be added in the future.

The following examples are commands that define a resource as a delegated resource:

RDEFINE CSFSERV CSFENC APPLDATA('RACF-DELEGATED')
RALTER  CSFSERV CSFENC APPLDATA('RACF-DELEGATED')
RALTER  CSFSERV CSFENC APPLDATA('THIS RESOURCE IS A RACF-DELEGATED RESOURCE')