IBM CICS RACF Security and Microsoft Windows Server 2003 Security

  • Article

This paper discusses how the security provided by the Microsoft Windows Server System, and in particular the Windows Server 2003 operating system, compares with the security available from IBM Resource Access Control Facility (RACF) and its third-party alternatives, and how it is commonly used in IBM Customer Information Control System (CICS) Transaction Server. Both products are designed for IBM mainframe z/OS operating systems, and its predecessors, such as OS/390.

This information applies for the following operating systems:

  • Microsoft Windows Server 2003

  • Microsoft Windows XP

  • Microsoft Windows 2000

It also applies for the following Windows Server System products:

  • Microsoft SQL Server 2000

  • Microsoft Windows Host Integration Server (HIS) 2004

General information about security in the Windows Server operating system can be found at https://www.microsoft.com/windowsserver2003/technologies/security/default.mspx.

The current version of this paper is maintained on the Web at https://download.microsoft.com/download/5/d/6/5d6eaf2b-7ddf-476b-93dc-7cf0072878e6/RACF-CICS.doc.

On This Page

Introduction Introduction
Purpose and Audience Purpose and Audience
What Is CICS? What Is CICS?
Terminal Unit-Based Identification Terminal Unit-Based Identification
Individual User Identification to CICS and Windows Server Individual User Identification to CICS and Windows Server
Data Access Control Data Access Control
Batch Applications: Program Access Control Batch Applications: Program Access Control
What CICS Does Not Protect What CICS Does Not Protect
Conclusion and Next Steps Conclusion and Next Steps
Terminology Terminology
Resources Resources

Introduction

This is a discussion of how Resource Access Control Facility (RACF) security works in a typical IBM Mainframe MVS (z/OS) CICS system today as it is generally used in most production shops and of the comparable security for programs running under the transaction monitor services of Microsoft Windows Server 2003. The information is largely the same for other popular mainframe security products, such as ACF2 and Top Secret from Computer Associates.

Purpose and Audience

This paper is written for IBM mainframe systems programmers, architects, and other mainframe professionals who are familiar with RACF- or ACF2-based security with CICS on MVS and z/OS, but who are not comparably familiar with security in Windows Server 2003.

Many users formed their initial impressions of Windows security from personal experience with desktop Microsoft Windows 3.x or Windows 95/98. These were not secure operating environments. Even those who use Windows XP often run "wide open" with full administrative privileges for all users, and are therefore not aware of the "lock down" capabilities available in the Windows Server and desktop operating system, and may never have used or become familiar with the security capabilities in Internet Information Services (IIS)-based transaction processing, Microsoft SQL Server database access, and others areas. This paper may help readers understand why, even on home computer Windows XP systems, they should be logged on with User IDs that do not have administrative privileges.

Because the audience for this paper is current mainframe professionals, familiarity with mainframe-specific terminology is assumed. For more information about some of the terms used in this paper, see the "Terminology" section in this paper.

What Is CICS?

This section is provided for readers who do not know CICS. If you are an experienced mainframe professional, you can skip this section.

CICS (originally Customer Information Control System) is a teleprocessing application monitor or "app-server" originally intended to:

  • Accept transaction input from terminals.

  • Process those "transactions" by calling the appropriate application program based upon a transaction code included in the terminal input.

  • Provide API services to those called programs (using EXEC CICS calls).

  • Send "responses" back to the originating terminal.

Today CICS also accepts program-to-program "calls" over the network (from CICS programs and other sources, including Microsoft Host Integration Server (currently HIS 2004) and routes them to the appropriate CICS program. This falls within a general network program calling category called APPC (Application Program to Program Communication). Today CICS supports the popular IBM host programming models. The ability to expose an XML Web Services interface that has recently been added.

The function of CICS is comparable to a Windows IIS server: taking input messages from the IP network and routing them to the appropriate Internet Server application programs, calling those programs with a particular set of conventions, and exposing callback APIs for use by the called program via the Internet Server API (ISAPI).

Terminal Connections to z/OS Terminal Applications

Historically, circa 1980, Virtual Telecommunications Access Method (VTAM) introduced the ability to dynamically "connect" IBM System Network Architecture (SNA) terminals to running VTAM applications, of which CICS became an example. SNA was in broad usage at that time. This created the need for individual user identification and authorization. With the advent of security facilities such as RACF, individual user-based identification and authorization became possible. When using a Windows workstation as a mainframe client, it is best if the Windows domain credential identity of the user logged on to the client workstation is passed through to a mainframe logon. This ideal single sign-on is sometimes achieved. More commonly a separate mainframe logon is required, which may be manual or carried out automatically by a front-end program that sits between the user and the now hidden from the user mainframe terminal screen image resident in application program computer memory.

  • There can be more than one CICS running on the same MVS system. Several instances of CICS can run the same or different applications for different groups of users.

  • The IMS Transaction Monitor (IMS/TM and formerly IMS/DC) and the MVS Time Sharing Option (TSO) are examples of other VTAM applications.

CICS Terminal Screen Choice-Based Access Control

CICS applications commonly control which transactions are available, at the current terminal location or to the identified logged-on user, by presenting a menu containing choices for only those transactions which the user is authorized to use. The starting "default" CICS application program typically displays a menu of options (transactions) available to the user, for example:

  1. Account Balance inquiry.

  2. Account Address change.

  3. Account Name Change.

  4. Open new account for existing customer.

  5. Open new account for new customer.

  6. Close customer account.

  7. Close customer’s last account.

Each of the above options represents a different transaction which may or may not be processed by its own unique program.

This method has been used as an assumed form of "role-based security," with the assumption that the menu of options insures that only the appropriate person (teller versus supervisor) could execute this transaction and perform actions that might be read-only or an update to stored information.

Security in MVS and z/OS

Note that neither z/OS nor the MVS family of operating systems provides security as part of the operating system. They rely on External Security Managers (ESMs) to provide security. When the operating system receives a request, that request is diverted by the Security Authorization Facility (SAF) within z/OS to an ESM. SAF directs control to either or both:

  • An ESM such as RACF or ACF2.

  • An organization supplied processing routine.

RACF from IBM is the most commonly used ESM. Others are ACF2 and Top Secret, both currently available from Computer Associates.

As originally designed and implemented, CICS did not have any security mechanism, nor did the underlying operating system. When security was added to the operating system in the form of the ESM and SAF to route request to the installed ESM, CICS was updated to call the ESM through the SAF interface at appropriate points in transaction processing.

Terminal Unit-Based Identification

In the simplest and most common case, security is based upon work location. In a more dynamic setting, security is based upon the identity of an individual user.

Historically, mainframe terminals were 1) hard-wired to the computer each with a permanent physical address, and 2) dedicated (allocated) to a single application. This fact combined with limiting who was allowed physical access to these terminals was, and sometimes still is today, the only security for transaction entry, application program use, or data access. This made it easy and natural to have security based on the assumed physical location of the terminal connection, such as the Customer Service Department. This is sometimes true even with today’s IP-based networks when these same applications are used from terminal emulators or front-end applications running on Windows or other client computers.

As originally designed and implemented, CICS did not have any security mechanism, nor did the underlying operating system. When security was added to the operating system in the form of the ESM and SAF to route request to the installed ESM, CICS was updated to call the ESM through the SAF interface at appropriate points in transaction processing.

Preset Terminal-Based Security

In CICS Transaction Server today, the descendent technology is called "preset terminal-based security" in which a USERID is specified in the terminal definition to the system. This associates a USERID permanently with a particular physical terminal and CICS implicitly "signs on" that preset USERID at that terminal. As discussed above, anyone with physical access to the terminal can enter the transactions authorized for that terminal, without the need to sign on to CICS (because the terminal is already signed on to the preset USERID). The only security is limited physical access. This is often used for terminals in locations such as a network control center and MVS consoles when used as CICS terminals.

Preset terminal-based security though does not allow any dynamic mapping of who can perform what actions and from which locations. In this case individual user identification is required.

Individual User Identification to CICS and Windows Server

The basis for individual user-based security is identification and authentication. The system must determine who the user is, or claims to be, and then authenticate that the user is who he or she claims (confirming their identity), and then "remember" the identity of that user or store a credential or token which represents that user.

For CICS on MVS, users are defined by an entry in the RACF database referred to as a user profile. Users identify themselves by specifying their RACF user identification (USERID) and the associated password, or an operator identification card (OIDCARD).

z/OS and CICS

Windows Server System

Users can "sign on" to CICS in one of two basic ways. Users can enter the CICS-supplied sign-on transaction, CESN, supplying their RACF user ID and password, or a program that is part of the application, or a "front end" to the application, can issue the EXEC CICS SIGNON command. On very old CICS systems, users are presented with a blank screen into which they key the CICS CESN logon transaction, somewhat analogous to a character mode command prompt in UNIX, Windows, or MS-DOS.

In a secure Windows deployment, a user must sign on to a Windows security domain in order to use a workstation (client computer). Logon is typically initiated by the familiar simultaneous depression of the CTRL+ALT+DEL keys or by another device that supplies user credentials. The type of credentials supplied by the user can be the common user ID and Password, or Smartcard and PIN, a biometric such as a thumbprint, etc. Note that one can also log on locally to an individual computer, as is common in a home computer or truly personal computer scenario.

RACF or another installed ESM verifies the user’s sign-on credentials.

The Windows Security Domain logon is validated by a Windows domain controller and a Kerberos v5 protocol ticket is issued for that user.

When a valid user sign-on occurs, CICS keeps track of the current signed-on user in a CICS area called the CICS User domain. CICS will pass this information to the ESM, for example RACF, when making authorization checks.

Windows stores credentials, such as the Kerberos v5 ticket, locally on the client computer in encrypted form. This identity information will be used to access protected objects, such as files, programs or data. This data does not include the actual user ID or password and is opaque to the application program.

There is a default CICS user, by default named "CICSUSER". CICS "signs on" the default user during system initialization. CICS uses the security attributes of the "CICSUSER" for input from terminals where no user is explicitly signed on.

IIS transaction services uses a provided default user account, by default named IUSR_MachineName, which provides the security context used when and if anonymous access is allowed. If anonymous user access is not enabled then the client must supply credentials, which with integrated Windows authentication are the security domain credentials of the user signed on to the client workstation computer.

Transaction and Program Access Control

In any case the user (or front-end program that is using the emulated terminal screen) is presented with the application in the form of formatted data field screen layouts and one of these fields, often hidden, is a transaction code.

z/OS and CICS

Windows Server System

When the user presses ENTER, or another program function key, CICS uses the transaction code as the key for a table lookup of what program should be called.

A client request is received over the network that contains the name of a script page with which a specific program is associated or in some uncommon cases the name of the program to be called.

CICS then calls the specified program passing in the formatted screen field data entered by the user.

IIS transaction services then calls the specified program, passing in the parameters (data) provided with the request.

When CICS is processing a transaction, the current user could be the logged-on user, or the default CICSUSER or the pre-set terminal-based security user name.

IIS transaction services switches to the security context of the requesting user, or if anonymous access is enabled then the anonymous IUSR_MachineName user context.

At appropriate points in transaction processing CICS checks with RACF (or another installed ESM) to see if the current user can proceed. At this execution point, CICS asks the ESM to verify that the current userID is permitted access to the entered transaction.

CICS uses the MVS SAF to route authorization requests to the ESM.

Each object, such as a file containing a script page or a program, has an access control list (ACL) of users and groups and their privileges. Windows attempts to access the named resource object, and Windows will either allow or deny access depending on the match between the ACL and the current user privilege.

If access is denied for the anonymous user, the user’s client computer is prompted to supply logon credentials.

You can also implicitly, that is, without programming, control access at a level more granular than the transaction. For example, you can control access to IMS databases, programs, and VSAM files that a CICS transaction uses.

You can protect any object in the system, which is implicit for common resources such as file, a databases (or view or stored procedure), another server (commonly a database server) or parts of the system itself such as the system registry.

You can control access to certain CICS commands, for example the EXEC CICS INQUIRE FILE command.

Command programs are protected objects.

In addition to the implicit security automatically provided by CICS, you can provide a more granular level of security checking within the CICS application program using the EXEC CICS QUERY SECURITY command. Some programs, CICS, batch, or others provide this more granular, lower-level security, for example to individual fields in a record, at the cost of considerable additional programming.

In addition to ACL-based security implicitly provided in Windows and its transaction services, you can provide more granular role-based security within your programs. This is done using the Windows Authorization Manager and the authorization programming interfaces commonly called the Authz APIs). (The older COM+ programming model also offered its own role-based security, now subsumed into Authorization Manager). From .NET managed code, these functions are available from the Microsoft.Interop.Security.AzRoles assembly.

Additional and more complex security is available for interconnected systems and for intercommunication between CICS regions in a single sysplex, using the CICS multi-region operation (MRO).

Individual security context propagates from server to server using the Kerberos capabilities built into Windows domain security and applies anywhere within a security domain.

If a program attempts to access a resource to which the current user does not have access rights, then CICS issues a "not authorized" (NOTAUTH) condition when this happens.

If a program attempts to access an object to which the current user does not have access rights, then that request fails and Windows returns "access denied". It is up to the requesting program to take appropriate action. For example, in an HTTP server scenario error condition "403 - access denied" may be returned to the client.

Data Access Control

In MVS CICS or Windows Server System, access to files or a database is controlled each with their own methods described below. The data in these datasets and databases must be available to transactional programs when processing certain transaction for some users, but not for others. This might simply be done at the file or database level, or a more sophisticated implementation can control access at a more granular level, for example to only certain portions of a database or data within, based on the identity of the user for whom the current transaction is being run.

Data Access Control with RACF and DB2 on a Mainframe

With RACF you can control access at the file, database, or table level, or you can restrict access or update at the individual dataset record field level or database row or column, but only with specific coding in the programs.

When coded to achieve field-level access control within records of a dataset, application programs use CICS file control in the normal way to read and update records. However, you must code the program to call QUERY SECURITY to determine whether the user has the authority to access particular field(s) within a record, and then it either proceeds to display or in some other way use the data or issue a message stating that the user is not authorized, depending on the value returned. Likewise, a program that updates a record would issue a QUERY SECURITY call to determine if the current user has update authority to that named data field. Depending on whether the value returned from the call indicates that the user has UPDATE access or not, the transaction would update the data file or indicate that the user is not authorized.

When controlling access at this more granular level, some mainframe shops may not apply resource security at the file level.

Data Access Control in the Windows Server System and SQL Server

Within the Windows Server System, access to a database server or a specific database or portions therefore is controlled like access to any other resource or object. In the case of a database, the protected resource is a database view or stored procedure. With Microsoft SQL Server running on Windows, permissions can be granted on a selected number of columns in a table and row level security can be implemented through a view, stored procedure, or function. Below is a list summary of this capability.

  1. Because managing column-level permissions can become complex, it is recommended that views be created to manage column and row-level security or alternately stored procedures or functions. These objects will specify the columns and rows to be accessed. Permissions should be granted on the view object rather than the underlying table.

    1. It is recommended that policy prevents users from having any form of direct access to any table. Instead, create views for every table and grant permissions only to those views through application roles.

  2. No explicit programming is required to protect specific rows or data columns. If a program is not allowed to read certain rows or columns, those rows and columns will not be returned in the view it is authorized to use.

  3. If Windows role-based security is used, then programming is required to determine the role of the current user and to check if that role is allowed to perform defined operations, similar to mainframe CICS QUERY SECURITY. With Windows role-based security, starting with Windows Server 2003, permissions are granted to roles, not to individual users. User membership in roles is externally administered, and NOT coded into programs.

  4. Permissions and user/application authentication are established for users, groups, or roles stored in the Windows security domain Active Directory, can be coordinated with LDAP directories via MIIS (Microsoft Identity Integration Server), and in the future will be dynamically modified between forests of external directories using ADFS (Active Directory Federation Services).

Batch Applications: Program Access Control

The datasets and databases used by the CICS or the transaction monitoring services in Windows and by the applications must be accessible only by approved batch processing and operations procedures, such as Backup. Data access by batch programs must be limited. In general a batch program should be authorized to access only "its own" data files.

With RACF on z/OS (or MVS generally):

  1. For each batch job, a user account is identified. The RACF user identity is created from information on the job card, including the JOBNAME and account field, and is usually derived and provided by an exit routine.

    1. Because the entire execution is run with a single user ID, batch programs are usually either read-only or update-allowed to entire files. Batch programs are generally not programmed to use field level, or database row/column level access control.

  2. Programs run within that job have access only to the data files to which that JOB’s "user" has permission.

  3. RACF control is available to limit which users are allowed to submit batch jobs or not, for example, which TSO users can use the SUBMIT command.

In Windows Server 2003 (or Microsoft Windows NT-based operating system versions generally):

  1. To run any program, an address space is created with a "default thread" running in a user security context. Every thread of execution always runs in the security context of some user, or a "built in" account such as "local System". By default this is the security context of the currently logged-on user who entered the command to start the program, but can be controlled:

    1. For example another user security context can be established if a program is started programmatically with the CreateProcessAsUser API. This API might be used, for example, by a job scheduling program.

    2. The Windows Service Control Manager starts NT Services under the user account identified in the specification for the service.

  2. When running the programs, privilege will be checked for each access to any protected object, for example any field or any database accessed through any view with restricted access.

What CICS Does Not Protect

Covered above are the mechanisms by which CICS can control access of individual CICS users to only certain transaction and programs and data, and by which CICS programs can be coded to provide data field-level access control. However CICS itself does not provide facilities to protect its own assets from external access. For example:

  • CICS does not offer protection from application programs that use undocumented or unsupported interfaces to bypass CICS security. You must use means outside of CICS to ensure that such programs are not installed on the system.

  • CICS does not protect application source libraries.

  • You must establish and follow procedures separate from CICS that prevent the introduction of unauthorized or untested application programs into "production."

Protection and Security of CICS

RACF data set protection is the primary means by which to prevent unauthorized access or alteration by, for example TSO Users or batch job programs. This protection must be extended to application programs, the application data, and also any persistently stored application output and the dataset that contain individual CICS definitions. The datasets and databases used by CICS and by CICS applications must be accessible only by approved batch processing and operations procedures. An MVS CICS shop must restrict access to the program libraries, to the CICS regions to only those users responsible to make application and system changes.

CICS and Windows Server Security Summary Comparison

Following is a summary comparison of security as provided by RACF to CICS on MVS and by the security that is integral to the Windows Server System. The factors chosen generally follow the activity flow of an end user who logs on and enters transactions.

Factor

CICS on MVS - z/OS

Windows Server System

Limited physical access security

Preset terminal-based

Windows workstation logon.

Preset terminal-based security / anonymous user access

Default "CICSUSER" privileges to all users

Default "IUSR_machinename" privileges to anonymous users.

Workstation user logon to centralized security domain

Windows Workstation logon not validated by RACF. However Windows User IDs and passwords can be synchronized with RACF.

Yes, Kerberos v5 using integrated Windows domain authentication and security mechanisms.

MVS mainframe / Windows Server user logon

Yes, and can be programmed

Yes. User security domain identity can propagate to server.

Storage of User Information

RACF Database

Microsoft Active Directory.

Single Sign-On to workstation and to MVS or Windows Server?

Not usually but can be achieved, for example Host Integration Sever 2004

Yes, unless measures are taken to prevent.

Sign on without clear text password passed on the IP network

Embedded in 3270 data stream.

Yes, integrated Windows authentication (no send of password on network, or http SSL encryption.

Automatically tracking of current user during program execution.

CICS stores current user in user domain area.

IIS Switches execution thread to current user’s context

Implicit automatic transaction and program access control

Yes. CICS call to ESM (via SAF).

Yes. Controlled by ACL on application home directory.

Access control on files

Yes.

Yes, through ACLs on files.

Access control to database.

Yes for IMS or DB2.

Yes, integrated Windows security SQL Server access control.

Granular DB Access Control

Yes. Table, row, column.

Yes. Table, row, column via ACLs on protected SQL objects, (Views and Stored Procedures).

Logging of authorized access

RACF Audit & Reporting

Yes (optional).

Logging of denied access

RACF Audit & Reporting

Yes.

Programmed access control

Yes, using:
EXEC CICS QUERY SECURITY

Yes, ACL-based or role-based.

Role-based access control

Yes.

Yes, using the Authorization Manager API (azMan).

Roles distinct from security "groups"

Yes.

Yes. Administration separate from domain administration.

Storage of role information

RACF Database & CICS Transaction Classes

Active Directory or XML "file."

Access control to "system"

Yes, if RACF is protected via RACF Database & CICS Transaction Classes

Yes, Windows integrated security.

Access control on commands

Yes, explicitly programmed, for example, CICS INQUIRE FILE

Yes, implicit by ACLs on file system directories containing command programs.

Conclusion and Next Steps

Software Developers, System Architects, and Security Administrators may discuss whether the underlying architecture of z/OS and the mainframe security components such as RACF are inherently more secure mechanisms than Windows Server, Active Directory, NTFS, and the Windows security components. However, the bottom line is whether the combination of components and processes in Windows and the mainframe minimize security breaches of the system. Early versions of both mainframe and Windows operating systems were deemed lacking on the security front, however in both cases well-managed datacenters run z/OS and Windows Server 2003 achieve very high levels of security and trust in the most security-conscious environments.

Mainframe professionals concerned about security, resource protection, identity management and authorization should become familiar with the capabilities of the current Windows Server System products and technology, and especially with security in Windows Server 2003. Resources for getting started are listed in the "Resources" section in this paper.

Terminology

In this document, some mainframe terminology may not be familiar to all readers:

  • ACL
    Access control list.
  • Active Directory
    The directory with the Windows system where user and other information is stored.
  • APPC
    Application Program-to-Program Communication.
  • BMS Map
    A CICS screen layout template, external to the CICS program.
  • ESM
    External Security Manager. An optional security facility that can, and almost always is, added to an MVS system. RACF from IBM is the most commonly used ESM. Others are ACF2 and Top Secret, both currently available from Computer Associates. Users can also write their own ESM.
  • NT Service
    A program automatically started by the Windows Service Control Manager (SCM). The SCM will only start services if their dependencies are met and the SCM monitors continue their execution. Somewhat analogous to an MVS Started Task.
  • Panel
    A TSO/ISPF screen layout template.
  • RACF
    Resource Access Control Facility, the MVS security component offered by IBM, originally introduced in 1976 (ten plus years after the introduction of the operating system that became MVS and today z/OS). In OS/390 and z/OS, RACF is part of the Security Server.
  • SAF
    Security Authorization Facility. The mechanism within the MVS operating system, which routes security requests to the installed ESM.
  • Screen
    The terminal display surface on which information is presented to the user. Called a screen because originally all terminals were based on glass Cathode Ray Tubes (CRT) superficially similar to televisions.
  • SSO
    Single Sign-On. When a user signs on only once to gain secure access to any system or subsystem or application or computer to which that user is privileged to use.

Resources

The following links provide additional information.