zCEE to call SAF for authentication

This is following on from RFE # 99337.

Since the last RFE was submitted, the zCEE authorization interceptor has been extended to allow even more groups to be defined for more granular control of the various operations and actions permitted within each of the four categories described above.

The approach described above is not a recognized SAF access control mechanism. It is simply assigning privileges based on RACF group names and permitting access based on RACF group memberships.

There are a number of issues/concerns with this approach:

- There is no security audit trail left by zCEE when inspecting group memberships. This introduces concerns for: event accountability; general activity auditing and reporting;reviewing and managing ongoing RACF access requirements.
It is understood that some (all?) successful (i.e. it does not register ‘violations') event information could be lifted from zCEE SMF record type 123 but we should not have to engineer a custom solution to attempt to assign accountability, and corresponding RACF group usage, because the product does not perform proper SAF access request calls.

- RACF Groups are an internal RACF construct to allow administrators to associate users with collections of RACF access (via entries in RACF rule ACLs) or to establish ownership hierarchies within RACF. The group name itself should have meaning only to RACF administrators. Any application that assigns meaning to a RACF group name, and associated group memberships, is at risk of impacts to availability issues/disruptions. RACF administrators could very easily remove or delete the groups as there is no apparent purpose for them (they provide no RACF access and there is no trail/evidence of them being used).

- Allowing the groups names to be configurable within zCEE allows a user with access to the configuration xml to change/add group names at will to potentially allow unauthorised elevation of access (e.g. add a group the offender is already connected to to the ADMIN group list).

- It compromises our security reporting as there are “invisible” accesses enjoyed by anyone connected to these groups … none of our reporting (nor any commercial security tools like zSecure/Vanguard) attributes any entitlements based purely on the membership of a group but rather the resources where groups or user ids appear on access lists. NAB security standards (indeed, industry best practice) dictates that users are provided only with that access required to perform their approved business function. The reports we use to review the access accounts are given versus the access they use in their business function will simply not include any of these zCEE entitlements. Further, automated processes may even remove people from these groups as no current access activity is being recorded against these groups.

This RFE is requesting that the zCEE authorization interceptor be updated to perform proper SAF access requests of resources managed in RACF for the purposes of managing access to the various operations and actions

e.g.
Say a user wants to use an ‘ADMIN' action called ‘adminaction' in an instance of zCEE that calls itself ‘zceeenv' (like a CICS prefixin CICS environment configuration). Let's also assume that zCEE uses RACF class ‘zceeclas' for all its resource rules. An authorised call like:

RACROUTE REQUEST=AUTH,ACEE=addr,CLASS='zceeclas',ENTITY='zceeenv.ADMIN.adminaction',ATTR=READ,LOG=ASIS (or using an equivalent callable service)

would ask RACF if the user associated with the request (part of the ACEE) has READ access to resource ‘zceeenv.ADMIN.adminaction'. RACF would then find the RACF rule in class ‘zceeclas' and use the rule's ACL (or public access: UACC) to determine if the user defined in the ACEE has READ access or not and would return an appropriate return code to the caller. Also, LOG=ASIS indicates that an SMF type80 subtype 2 (RACF access request) record would be cut depending on the audit option on the protecting RACF rule or on the userid or on the RACF class.

This approach is far more flexible; more secure; it uses a standard SAF interface for access control; and auditing, accountability can be properly reviewed and managed.

zCEE already performs some SAF authorization calls against the RACF APPL class and the EJBROLE class to verify a client's authority to connect to zCEE initially. Why does zCEE not continue with this for the authorization of the various actions and operations?