Mainframe > Administrator > Security

RACF Group Trees Implementation and Use

Implementing and using RACF structures.

Note: This is the second of a two-part article series. The first part can be found in the November 2006 issue of the magazine.

In the first part of this series on the Resource Access Control Facility (RACF*) group tree, I covered the basics of groups and user IDs and some detail on group-level attributes and authorities. In this article, I'll expand on this knowledge with greater detail on the implementation and use of these structures, illustrated with some real-world examples.

To recap last issue, I described the basic RACF group tree and various types of common groups. To fully appreciate groups, I then needed to introduce some detail about user IDs and their interaction with groups - specifically the user IDs default group and owning group. Lastly, I introduced the concept of group privileges, technically known as attributes and authorities, which I'll explore more in this article.

Perhaps the most important point to appreciate from my previous article is that the RACF group tree itself provides no resource-access privileges. The group tree is purely an administrative construct used in the management of RACF and not in the granting of access to z/OS* resources. This is sometimes a challenging concept to appreciate, especially if the reader is more familiar with alternate z/OS security managers.

RACF groups are used to grant access to resources by virtue of being in the access list of RACF profiles. The structure of groups, subgroups and superior groups is totally unrelated to gaining access to resources. There's no concept of "inheritance" or any real relationship between the access rights granted to one group and those granted to another. The only reason for the existence of the group tree - and by corollary the preference to have a meaningful structure in your group tree - is to confer RACF administrative privileges, which are quite distinct from RACF access rights.

One of the fundamental principles of security management mandates staff only have access to the resources required to perform their role or job function - as such, RACF separates the security administration role from the access rights the administrator manages. This seems like a strange concept to those familiar with UNIX* technology-based systems, where system administrators have full access to all resources and data being managed by their systems. RACF can provide separation of the administrative role from the end-user roles. The security administrator can manage the access rights of users, where the administrators themselves have no access to the resources these users need.

Tweet