MAINFRAME > Tips & Techniques > Application Development

Role-Based Access Control for RACF

RBAC is increasingly popular and enhances the efficiency of the security analysts and administrators.

RBAC is increasingly popular and enhances the efficiency of the security analysts and administrators.

Role-based access control (RBAC) has become an increasingly popular phrase across all IT security-management frameworks to describe the process by which users are classified into roles - or job functions - within the IT security framework. The idea is that managing roles rather than individual user-access rights improves the security implementation's effectiveness. It also enhances the efficiency of the security analysts and administrators.

The challenges to an effective RBAC implementation lie in the IT security system being used and its ability to present a role-based view of the individual user-access rights. This article outlines techniques and structures that can be established in your RACF* database to assist in conforming to or defining a true role-based access framework.

Job Functions

The RBAC concept isn't new to experienced RACF administrators. Although the term RBAC may not have been applied previously, mainframe RACF administrators have been implementing RBAC-style solutions for many years. Most of these implementations have been based on a concept sometimes referred to as job functions. A job function is the set of IT security access rights an employee requires to perform a job - employees may have many "jobs" and thus require more than one job function. In RACF terms, job functions are commonly implemented as a group or set of groups that grant specific levels of access, usually within a single application system. For example, the RACF groups PERSUPDT and PERSREAD would be used respectively to grant UPDATE and READ access to the personnel system and only the personnel system.

When it comes to actually implementing RBAC in a RACF environment, security practitioners tend to fall into one of two camps: the "one RACF group per role" and the "many RACF groups per role." In the first group, implementation of the entire set of privileges necessary for employees to perform their jobs is assigned to one RACF group. A single RACF group represents the role. In theory users based on this role would have only the one RACF group in its list of connected groups.

In the "many groups" implementation, a specific RACF group better represents a job function rather than a role. When I use the term job function I intend it to mean one RACF group. Using the "many groups" approach, RACF's list-of-group concept can be exploited when designing roles. Groups are used to represent access to a single application or a level of access within an application. It's possible that several groups may be required for some levels of access to just one application system.

Most users would have a small number of groups provide access only to the applications they require. Senior staff and systems administrators might share some of these groups, but would have additional groups representing higher levels of access to those or other applications.

I personally prefer the "many groups" approach to RBAC with RACF for two reasons. First, most RACF installations considering an RBAC framework will have users with many groups already. Second, this approach exploits RACF more fully, giving us flexibility in how we design RACF group structures to represent roles. In this approach the definition of a role becomes a collection of RACF groups - each representing a specific job function. An employee will require one or more job functions in order to perform their duties.

For a list of the pros and cons for each group choice, see the sidebar "Pros and Cons".

Michael Cairns works for IBM as a technical specialist in the Tivoli zSecure range of software. Michael can be reached at

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

A Beginner's Guide to the REXX Programming Language on z/OS

Reading and Writing Files in the REXX programming language on z/OS.


Application Management is Important to the Entire Process


Application Testing: Giving Users What They Need

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters