Mainframe Security and Identity Access Management

By Corbin Links


[October 2014 Update: The mainframe security article continues to garner a lot of interest. In fact, I got two calls on it just this week! Looking at it with fresher eyes, I realized it needed a bit of a cleanup. The original remains more or less in tact, but some text changes are added for readability.

Please note: The original report was published back in early 2006, almost 9 years ago. Mainframe integration options, including improved bridge technologies, modules, middleware, gateways, and other technologies have improved substantially. The original article is still valid from a security and political/budgetary perspective. But now, CA, IBM, Attachmate and others have begun to address many of the traditional challenges.

I recommend viewing this article as a springboard or “overview summary” for further research.

If you need to understand identity access management (IAM / IdM) at a deeper level, I encourage you to grab a copy of my book IAM Quick Start Guide — 2014 Gold Edition. Just click the button.

] [July 2013 Update: Due to the recent resurgence in mainframe-related search traffic and overall interest in all things “legacy”, I’m reposting this classic.

NOTE: If you’ve read the original, you’ll note a few minor modifications to reflect new phone numbers and contact information. The pictures have also been added back in. Everything else is provided in its legacy-but-still-oh-so-relevant-today goodness.


The other day, a client asked me about mainframe security. If you’ve  been involved in — or are about to be involved in — large identity management (IAM / IdM) programs, mainframes and “legacy systems” will pop up at some point.

When the inevitable “what do we do with our legacy stuff” conversation comes, some may say “mainframes are dead, why talk about it?”

Others will say “sure we have them, but why integrate them at all?”

And members of the more pragmatic camp, will say “Like it or not, our mainframes are strategic assets core applications and data. We need a path forward.”

Ok, I’m paraphrasing a bit, but not too much… Mainframe integration with IAM — or any enterprise program — is challenging at best. Technical challenges, political, support, and budgetary challenges all leave their mark.

Be that as it may, mainframe systems and technologies remain a vital component of many large organizations, especially large financial institutions, insurance companies, and governments. I like to avoid the “why mainframes?” question, because in the end, the “why” doesn’t matter as much as understanding the “what” and the “how.” As an IAM implementation and planning team member, you WILL come across that all-important mainframe system; you WILL need an integration plan of some form or fashion.

The following report was commissioned by Links Business Group LLC early last year for a couple of clients requesting a good survey of mainframe security systems. It is being posted here for reference and background information. Hope you find this useful, and please keep in mind that this article is copyrighted material. Please reference it by full link to our site, and attribution only.

Ready to mainframe? Here we go!

Foreword to: Mainframe-based Authentication and Authorization Systems

The following report Mainframe-based Authentication and Authorization Systems is presented as an introductory overview. We have written before on the subject, referencing the fact that most enterprise-sized IAM Programs will eventually encounter mainframe systems, and the need to find an integration strategy – or leave them out of program scope entirely. Organizations that use mainframe technologies often have complex mixed-authentication systems which also leverage one or more UNIX and/or Windows-based systems and various third-party systems.

Mainframe-based systems present the following challenges to the IAM Program:

  • Lack of internal expertise, or limited access to Subject Matter Experts (SME)
  • Lack of test environments to validate IAM integration testing
  • Limited mainframe technology support from IAM vendors
  • Extensive use of in-house/internal developed applications which reside on the mainframe
  • Training and retraining issues
  • Limited support for applications residing on the mainframe
  • Limited migration paths for some types of mainframe-based data, and Digital Identities

Finding good mitigation strategies for the preceding issues can be crucial part of any enterprise-scale IAM program.

In this report, we provide an overview of what mainframe systems are, and what their security models look like. The intent of this report is to provide background and overview information that can be used by your planning and technical implementation teams.  

1.   Introduction

1.1. Background and purpose


As computer technology evolves so, too, does the complexity and sophistication of computer viruses.    If you own a PC connected to the internet chances are you know this firsthand. Despite increasingly powerful anti-virus software and fire-walls any PC is vulnerable to the latest hackers’ brainchild.

On the other hand, mainframes, although accessible to multiple users, are generally considered reasonably secure. An old mainframe term, RAS, which stands for “reliability, availability, serviceability”, suggests that mainframes do not break down or stop working as PCs frequently do. (Philipson 2002). In fact, van Hoboken (2004) claims that “complacency and overconfidence” on the part of the organisations which use them constitute the biggest threat to mainframe security.

Two related concepts are involved in combating this threat: authentication which refers to the process of verifying the identity of any user trying to access the system and authorization which is concerned with the identified user’s authority to access specific resources. The purpose of this paper, then, is to provide a basic understanding of the major mainframe-based authentication and authorization systems – RACF, CA-ACF2, and eTrust CA Top Secret, and to discuss the role of Identity Management. Before this purpose can be realized, however, it is important to ensure a common perception of the concepts of mainframe systems and security.

1.2.   Basic Concept of a Mainframe computer

The term ‘mainframe’ conjures up in many PC users’ minds the image of a monster computer housed in its own room (or building) bristling with vacuum tubes circa 1939.

In fact, Graeme Philipson (2002), who is a self-proclaimed mainframe guru reports that he was taken aback when asked, a few years ago, whether mainframe computers still exist Despite predictions to the contrary (van Hoboken 2004; Laberis 2003) we are pleased to announce that reports of “the mainframe’s demise (have been) greatly exaggerated” (Laberis 2003).

Nevertheless, although Philipson was surprised at the question even he had difficulty giving a precise description of the system, stating that no standard definition exists and that the mainframe has been identified variously by size, price or make.  

Encarta’s definition of a mainframe as “a high-level computer designed for the most intensive computational tasks” and often shared by multiple users connected to the computer via terminals” probably comes closest to explaining its function.

Today mainframe systems can be found in most large organizations, from major banks to the World Wide Web, in fact, Peterson suggests that up to 70 percent of the world’s most important business data” is still to be found on mainframe servers (2006). This being the case, ensuring the security of this vital data is crucial.

1.3.   Mainframe Security

Rob van Hoboken (2004), in his article Mainframe’s midlife crisis: Security, identified three major security threats: malicious data access; self-inflicted mistakes and aged software. The latter two are beyond the scope of this paper but, nevertheless, warrant a brief discussion:

Self-inflicted mistakes, according to van Hoboken, are the result of the fact that, in the wake of the retirement of many mainframe master technicians, their places are often filled with staff members who are less qualified, less experienced and very often overworked. This is a recipe for disaster, however inadvertent.

Aged software can be linked to the concept of RAS mentioned in 1.1.   The strength of the mainframe, i.e. the ability to “continue to run the old reliable software without too much maintenance” can become its weakness if security checks and updates are neglected.

The issue of malicious data access is the thrust of this paper. Van Hoboken (2004) states that mainframes are as vulnerable as any other platform to intrusive and damaging access not only from hackers but also from trusted users. De Voney (2007) supports this, pointing out that even if the infrastructure is able to successfully deny intrusion to hackers; “authorized people with inadvertent or malicious actions” can threaten the integrity of the data base. Hence the need for reliable authentication and authorization systems.

In the following section we will be considering three of the major mainframe-based authentication and authorization systems – RACF, ACF2, and eTrust CA Top Secret.

2.    Mainframe-based Authentication and Authorization Systems

2.1. RACF

Despite recent challenges from ambitious competitors (McDougall 2007), IBM holds the world wide monopoly for mainframe computers, so any security system which is not compatible with IBM systems, and, in particular, the z-Series mainframes, has a limited applicability in the business world. The Resource Access Control Facility (RACF) is an IBM product. This particular security system has been around since 1976 and is “a central component of IBM’s mainframe security efforts” (Peterson 2006).

Before looking at the function of the RACF it will be useful to consider the security needs of a mainframe system which is accessible to a large number of users. Peterson (2006) lists the following requirements:

  • Identification and authentication – enable users to establish and validate their identify to the system
  • Access control – restrict user access to protected resources.
  • Data confidentiality – avoid disclosure of sensitive data to unauthorized parties
  • Data integrity – prevent or detect any alterations to data
  • Nonrepudiation – ability to validate origin and authenticity of messages.
  • Security management–Administrative processes to create and maintain a security policy.

Accepting that these are the basic security needs of the mainframe system, the authentication and authorization functions of each of the three major security systems will be examined in order to establish whether they comply with the requirements.

Identification and authentication are the most fundamental roles of identity management. The RACF uses an alphanumerical user ID to identify the user trying to access the system. The term ‘user’ does not, in this case, necessarily imply an individual as the user ID can also be linked to, for example, a group, an ongoing task or a batch job (de Graaf et al 2000; Security Service RACF n/d).   The user’s identity is then verified, or authenticated, through the use of a password.

Although the combination of user ID and password is a basic and effective means of ensuring the authenticity of the user, RACF also accommodates a number of alternative methods. These include a pass ticket which functions as a once off password, is valid for 10 minutes, and is usually generated by RACF; an operator identification card (OIDCARD) which can be used in place of a password, or in addition to one, thereby providing extra security and a digital certificate which is the equivalent of a identity document, validated and issued by an independent certification authority (Security Service RACF n/d).

Access control, data confidentiality and integrity can all be addressed under the heading authorization.   RACF categorizes resources, either data sets or general resources, into resource profiles which contain information about the description of the resource, “the authorized users and the access authority of each user” (de Graaff et al 2000). By checking the profiles RACF is able to determine which users are authorised to access resources and how and when they authorised to do so.

Users’ requests go through the resource manager which directs RACF to determine whether the user has the necessary authority. This it does by accessing both the user and the resource profiles and comparing the security levels and list of categories in both. RACF then passes the result code back to the resource manager which either grants or denies the request. (Security Services RACF n/d; Peterson 2006)

The following diagram, taken from IBM Corporation’s document, Security Services RACF clearly illustrates the process:


Figure 1 Example of RACROUTE REQUEST=AUTH Processing (Security Services RACF n/d).


Not shown in the diagram is the SAF (System Authorization Facility) which “is the security foundation of every z/OS system” and which provides an interface between the Resource Manager and RACF (Wunderlich et al 2003).

Finally, RACF assists in security management by maintaining a log of the number of times a user enters the system and the number of times any one user accesses a specific resource. In addition RACF facilitates the detection of security threats to the system by detecting and recording:

  • Unauthorized attempts to enter the system
  • Authorized or unauthorized attempts to access RACF-protected resources
  • Authorized or unauthorized attempts to enter RACF commands

(Security Server RACF n/d)

Overall, this brief review suggests that RACF complies with the requirement needs of a mainframe system as postulated by Peterson (2006). The following two security products are manufactured by Computer Associates (CA) but are IBM compliant.

2.2. ACF2

Computer Associates’ Access Control Facility (ACF2 or CA-ACF2) approaches identity management in much the same way as RACF. In order to identify and authenticate users ACF2 requires a valid logon ID (LID) combined with a current password.

The resource profile in CA-AF2 is called a rule set. Both data sets and general resources are protected by rule sets which describe the resource and define the access levels and user authorizations (de Graaff et al 2000).   Authorization is granted if there is a match between the user’s LID and the information in the rule set. However, implicit authorization may also be granted by privilege values in the user’s LID, the level of administrative authority or privilege depending upon the user’s position or job function. Examples of these privileges include Account privileges which allow administrative access to LID’s in the database and READALL privileges where the user is granted READ access to all data sets whether or not the user’s LID complies with the rule set (de Graaff et al 2000; CA ACF2(TM) r12 for z/VM 2007).

The authorization process is similar to that of RACF with the exception that ACF2 uses a non-standard SAF module. ACF2 also modifies some Resource Managers, such as the CICS. As a result “not all RACROUTE macros will behave the same as in a standard RACF/SAF environment” (Wunderlich et al 2003). (See Figure 1).

This process is illustrated in the following diagram:


Figure 2   CA-ACF2 Information Flow (de Graaff et al 2000).

CA-ACF2 also provides security management beyond the identity management issues of authenticity and authorization. All potential security threats are audited and recorded. These include any modifications to the security system, access or attempted access to data sets and changes to the security databases. In addition, CA-ACF2 allows for the separation of different administrative functions through the use of privilege values, ensuring that users only have access to those resources which are necessary for them to carry out their duties (CA ACF2(TM) r12 for z/VM 2007).   By separating administration and audit functions, enabling them “to check and balance each other” (van Hoboken 2004), CA-ACF2 provides “an additional management control” that safeguards the security system and helps to ensure that the integrity of the security records is preserved (CA ACF2(TM) r12 for z/VM 2007).  

2.3.       eTrust CA Top Secret

Top Secret is the third of the major mainframe-based authentication and authorization systems. This product, too, provides identity management in the form of controlled access to resources and user authorization, as well as supplying logging and reporting facilities (MyFutureCom n/d).  

The Top Secret user ID is called an ACID (Accessor ID) and the access privileges which are linked to the ACID are profiled in the user’s Security Record.   All security records are maintained in an encrypted database, the Top Secret Security File” (Barker 2002).  

The structure of Top Secret is hierarchical in nature with the ACID’s being classified into different zones. There are six of these zones which are listed below from the highest to the lowest level:

Zone ACID – the highest level within Top Secret. It allows the organization to be split into several subsections. All other ACIDs and resources are defined to a zone.

Division ACID – allows definition of subsections within each zone. Departments, profiles, groups, and users are defined to each division.

Department ACID – allows for logical separation of users based on job functions (i.e. Accounts Payable, Programming, Finance, etc.). Users and groups are defined to their respective departments.

Group ACID – allows grouping of users that share similar access requirements. Groups and profiles are very similar.

Profile ACID – allows grouping of common resource access requirements. Then users can be defined to profiles rather than creating separate access permissions for every individual user ACID.

User ACID – designates a specific user and must be associated with a single department.  

(Barker 2002).

Although this multiplicity of levels has the potential to make security management a nightmare, it does facilitate the separation of administrative duties, limiting access to sensitive databases and so helping to preserve the integrity of the system. (See ACF2).

Like the other two security systems security management in Top Secret is assisted by the provision of a number of programmes which help to monitor security violations and track and report access to resources.

Although there are some differences in the processing of data between RACF, CA-ACF2 and eTrust CA Top Secret, all three security systems appear to meet the basic security requirements of a mainframe system. However, Top Secret’s 19 hour blackout on June the 16th last year (Naraine 2007) has brought into question the overall reliability of mainframe security systems.

3.      Mainframe Security: Good Enough for the 21st Century?

In his article, Mainframe Security: Good enough for the 21st Century?De Vito (2003) poses the same question. His answer is that, while security systems such as RACF, CA-ACF2 and Top Secret might make illegal access of data more difficult, no system is infallible. No mainframe stands alone, links to a network of PC’s, other mainframes and web-based products which provide a connection to the internet means that every mainframe today is vulnerable to threats both from trusted users and hackers (See 1.3).

Exacerbating the problem is the need to meet government privacy requirements. Regulatory and legal requirements may differ from country to country but most require an organization to investigate and identify the “legal requirements for information security or reliability that may apply” to its situation and to comply with these regulations (ISO 17799 Information & Resources). One example is “the Sarbanes-Oxley Act, which makes it a crime for any company to impair an object’s integrity” (De Vito 2003).

Cryptography is one way to help preserve the integrity of the database. Encrypting data not only means that it cannot be deciphered or altered, it also ensures that the identity of the sender is indisputable (De Vito 2003) .

IBM is one of the few manufacturers which offer a hardware solution. Its mainframe’s operating system, z/OS, in conjunction with the Cryptographic Coprocessor hardware device, helps to prevent access to sensitive information — such as customers’ credit card information, addresses and social security numbers — by unauthorized users (IBM Boosts Mainframe Security 2007). There are, however, a number of software solutions available, such as that used in the Top Secret Security Files.

4.      Conclusion

This paper set out to provide a basic understanding of the major mainframe-based authentication and authorization systems – RACF, CA-ACF2, and eTrust CA Top Secret. In doing so the security requirements of a mainframe system had to be taken into account. Despite some differences in the information processing of the three systems all of them met these requirements. However, in the light of regulations aimed at ensuring the privacy of sensitive data and with the growing vulnerability of mainframes to insider and outsider security threats, the need for greater vigilance in providing mainframe security has become evident.

Mainframe systems have you challenged? Need help deciding how or if to proceed with mainframe integration for your IAM Program? Call Links Business Group LLC today at +1 800 507 3480,


CA ACF2(TM) r12 for z/VM (2007). Retrieved 19 January 2008 from         

Barker, C. (2002). Mainframe Security featuring CA-Top Secret. The SANS Institute.

Retrieved 20 January 2008 from

De Vito, A. (2003). Mainframe Security: Good Enough for the 21st Century?

                  Enterprise Systems. Retrieved 20 January 2008 from

De Voney, C. (2007). Moving security to the mainframe.Retrieved 19 January 2008


de Graaff, P., Anderson, T.,Bergh, J., Desforge, P., Kearney, L., Kikuchi, L.H., Nix, T., &

Shell, M. (2000). CA-ACF2 to OS/390 Security Service. International Technical Support Organization. Retrieved 19 January 2008 from

FutureCom (n/d). eTrust CA-Top Secret Security. Retrieved 19 January 2008 from

IBM Boosts Mainframe Security. (2007). IBM Corporation. Retrieved 20 January 2008


ISO 17799 Information & Resources (n/d) Retrieved 20 January 2008 from


Laberis, B. (2003). IT’s Main Squeeze.MC Marketing Computers. Retrieved 19

                  January 2008 from


McDougall, P. (2007). Attack of the clone: Mainframe maker counter sues IBM.

Channel Web Network. Retrieved 9 January 2008 from

MSN Encarta (2008). Retrieved 19 January 2008 from

Naraine, R. (2007). CA Mainframe Security Blacked Out Globally. eWeek Security

Watch. Retrieved 20 January 2008 from

Peterson, D. (2006). Ensuring Security On IBM Mainframes. Business

Communications Review. Retrieved 19 January 2008 from

Philipson, G. (2002). Calling a mainframe computer by any other name. The

Sydney Morning Herald. Retrieved 19 January 2008 from

Security Service RACF (n/d). IBM Corporation. Retrieved 19 January 2008 from

van Hoboken, R. (2004). Mainframe’s midlife crisis: Security.Computer World.

Retrieved 19 January 2008 from,10801,89302,00.html

Wunderlich, H., Boche, U., Briggs, J., Diaz, J., de Gilio, F.J., Hackett, T., Landenberger,

A. & McCarthy, E. (2003). z/OS WebSphere and J2EE Security Handbook.IBM Corporation. Retrieved 19 January 2008 from


   HSM – Hierarchical Storage Management

   CICS/VS – Customer Information Control System/Virtual Storage

If you need to understand identity access management (IAM / IdM) at a deeper level, I encourage you to grab a copy of my book IAM Quick Start Guide — 2014 Gold Edition. Just click the button.


About the Author

Corbin Links -- Health Nut, Nutritionist, Tech Warrior, Business IT Strategist and Consultant, Author, Podcaster, Blogger, and Other Duties as Required.

Corbin Links January 14, 2009

FYI – Graphics now fixed, and should display as intended

Comments are closed