Enhance RACF-DELEGATED support for FTP to include when z/OS is the FTP client

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - z Systems Software
Product - z/OS Communications Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Enterprise Networking
Product - z/OS Communications Server

This requirement would need to be addressed via RACF. As RACF is not yet using RFE for requirements management, a FITS requirement (MR1212123050) has been opened against RACF. This RFE will be closed.

I was actually afraid RACF delegated wouldn't work here as the FRACHECK is occuring inside of my address space and of course where else could the FRACHECK occur when my address space is running as a client of some other server.

That solution of creating a group for the users of FTP won't really work here at Publix due to audit restrictions. They view anything related to crypto as something that has to be audited every quarter. So if I build that group as you suggest multiple managers will be re-approving this access QUARTERLY unil the end of time.

I've often though of just opening profiles like this up to everyone with a UACC of READ because who really cares what FTP sessions are crypto accelerated vs. which are not but after a conversaion with level 2 via a PMR I understand the idea is that you don't want just anyone able to find out what APIs your crypto hardware supports.

The only other thing I could think of is delete our ** profile in the CSFSERV class which would default the SAF return code to a 4 because CSFSERV defaults to a 4 if no profile is found. Then perhaps because NO profile is found it works. But that goes against what I see in the manual.

Perhaps program control? But implementing PADS is painful unless I wish to program control every load library the FTP users might ever use and some of them have access to TSO. Ugh.

What other possible solutions might IBM be capable of coming up with?
I was hoping for a technological enhnacment of some kind of ease the burden of my particular situation.

Thanks,
Joel

The suggested solution of using RACF delegated access does not fit for the FTP client because the client runs directly under the invoking user's address space. In other words, there is no other userid that to which access can be delegated (with FTPD, the delegation is handled by the userid of the FTP daemon address space).

However, I believe the problem is easily solved through the use of RACF groups. Here's what I suggest. (Note that the complete command syntax is not shown - just enough to get the point across.)

Create a group profile for all FTP client users:

ADDGROUP FTPCLNTS OWNER(ownerid) SUPGROUP(superior group, if any)

Permit the new FTPCLNTS group to all of the required CSFSERV resources:

PERMIT profile-name CLASS(CSFSERV) ID(FTPCLNTS) ACCESS(READ)

Connect the required userids to the FTPCLNTS group:

CONNECT userid GROUP(FTPCLNTS)

After setting up the group this way, any userid that's a member of the group will have access to the permitted CSFSERV resources. In addition, the use of the group adds exactly one entry to the the ACL list for each profile, which should address your concern about building long ACLs.

Does this appear to be a viable solution to your request?