RACF and Common CICS Security

WinHEC 2005 Update - April 20, 2005

Abstract This paper provides an understanding of 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 IBMs 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 on security in the Windows Server operating system can be found at http://www.microsoft.com/windowsserver2003/technologies/security/default.mspx. The current version of this paper is maintained on the Web at http://www.microsoft.com/whdc/winhec/papers05.mspx. Contents
Introduction .............................................................................................................................3 Purpose and Audience.............................................................................................................3 What Is CICS? ........................................................................................................................3 Terminal Connections to z/OS Terminal Applications....................................................................................3 CICS Terminal Screen Choice-based Access Control...................................................................................4 Security in MVS and z/OS.............................................................................................................................4 Terminal Unit-Based Identification...........................................................................................5 Preset Terminal-Based Security....................................................................................................................5 Individual User Identification to CICS and Windows Server....................................................5 Transaction and Program Access Control.....................................................................................................6 Data Access Control................................................................................................................7 Data Access Control with RACF and DB2 on a Mainframe...........................................................................7 Data Access Control in the Windows Server System and SQL Server.........................................................8 Batch Applications: Program Access Control..........................................................................8 What CICS Does Not Protect...................................................................................................9 Protection and Security of CICS ...................................................................................................................9 CICS and Windows Server Security Summary Comparison.........................................................................9 Conclusion and Next Steps....................................................................................................11 Terminology...........................................................................................................................11 Resources..............................................................................................................................12

Erro! Estilo no definido. - 2

Disclaimer This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. 2005 Microsoft Corporation. All rights reserved. Active Directory, Microsoft, MSDN, MS-DOS, Win32, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

WinHEC 2005 Update - April 20, 2005 Preview Draft

Erro! Estilo no definido. - 3

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 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 mainframespecific terminology is assumed. For more information on some of the terms used in this paper, see the Terminology section in this paper.

What Is CICS?
This section is provided for readers that 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 Microsofts 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 SNA terminals to running VTAM applications, of which CICS became an example. SNA is IBMs System Network Architecture which was in broad usage at that time. This

WinHEC 2005 Update - April 20, 2005 Preview Draft

Erro! Estilo no definido. - 4

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: a. b. c. d. e. f. g. Account Balance inquiry. Account Address change. Account Name Change. Open new account for existing customer. Open new account for new customer. Close customer account. Close customers 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.

WinHEC 2005 Update - April 20, 2005 Preview Draft

Erro! Estilo no definido. - 5

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 todays IP-based networks when these same applications are used from terminal emulators or front-end applications running on Windows or other client computers.

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 they claim (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 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. RACF, or another installed ESM verifies the users sign-on credentials. Windows Server System 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. The Windows Security Domain logon is validated by a Windows domain controller and a Kerberos v5 protocol ticket is issued for that user.

WinHEC 2005 Update - April 20, 2005 Preview Draft

Erro! Estilo no definido. - 6

z/OS and CICS 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, e.g., RACF, when making authorization checks.

Windows Server System 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. 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.

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.

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 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. CICS then calls the specified program passing in the formatted screen field data entered by the user. When CICS is processing a transaction, the current user could be the logged on user, or the default CICSUSER or the pre-set terminalbased security user name. 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 useri ID is permitted access to the entered transaction. CICS uses the MVS SAF to route authorization requests to the ESM. Windows Server System 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. IIS transaction services then calls the specified program, passing in the parameters (data) provided with the request. 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. 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 users client computer is prompted to supply logon credentials. 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

You can also implicitly, i.e., without programming, control access at a level more granular than the transaction. For example you can control access to IMS databases,

WinHEC 2005 Update - April 20, 2005 Preview Draft

Erro! Estilo no definido. - 7

z/OS and CICS programs and VSAM files that a CICS transaction uses. You can control access to certain CICS commands, for example the EXEC CICS INQUIRE FILE command.

Windows Server System parts of the system itself such as the system registry. 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 rolebased 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 function are available from the Microsoft.Interop.Security.AzRoles assembly. 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 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.

Additional and more complex security is available for inter-connected systems and for intercommunication between CICS regions in a single sysplex, using the CICS multi-region operation (MRO). 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.

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 one can control access at the file, database or table level, or one 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 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

WinHEC 2005 Update - April 20, 2005 Preview Draft

Erro! Estilo no definido. - 8

would issue a QUERY SECURITY call to determine if the current user has update authority to that named data field. Depending on if the value returned from the call indicates that the user has UPDATE access, 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. a. 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. a. 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 JOBs user has permission. 3. RACF control is available to limit which users are allowed to submit batch jobs or not, e.g., which TSO users can use the SUBMIT command.

WinHEC 2005 Update - April 20, 2005 Preview Draft

Erro! Estilo no definido. - 9

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: a. For example another user security context can be established if a programs is started programmatically with the CreateProcessAsUser API. This API might be used, for example, by a job scheduling program. b. 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 Limited physical access security Preset terminal-based security / anonymous user access CICS on MVS z/OS Preset terminal-based Default CICSUSER privileges to all users Windows Server System Windows workstation logon Default IUSR_machinename privileges to anonymous users.

WinHEC 2005 Update - April 20, 2005 Preview Draft

Erro! Estilo no definido. - 10

Factor Workstation user logon to centralized security domain

CICS on MVS z/OS Windows Workstation logon not validated by RACF. However Windows User IDs and passwords can be synchronized with RACF. Yes, and can be programmed

Windows Server System Yes, Kerberos v5 using integrated Windows domain authentication and security mechanisms. Yes. User security domain identity can propagate to server. Microsoft Active Directory Yes, unless measures are taken to prevent. Yes, integrated Windows authentication (no send of password on network, or http SSL encryption. IIS Switches execution thread to current users context Yes. Controlled by ACL on application home directory. Yes, through ACLs on files. Yes, integrated Windows security SQL Server access control. Yes. Table, row, column via ACLs on protected SQL objects, (Views and Stored Procedures). Yes (optional). Yes. Yes, ACL-based or rolebased. Yes, using the Authorization Manager API (azMan). Yes. Administration separate from domain administration. Active Directory or XML file.

MVS mainframe / Windows Server user logon Storage of User Information Single Sign On to workstation and to MVS or Windows Server? Sign on without clear text password passed on the IP network Automatically tracking of current user during program execution. Implicit automatic transaction and program access control Access control on files Access control to database.

RACF Database Not usually but can be achieved, e.g. Host Integration Sever 2004 Embedded in 3270 data stream.

CICS stores current user in user domain area. Yes. CICS call to ESM (via SAF). Yes Yes for IMS or DB2.

Granular DB Access Control

Yes. Table, row, column.

Logging of authorized access Logging of denied access Programmed access control Role-based access control

RACF Audit & Reporting RACF Audit & Reporting Yes, using: EXEC CICS QUERY SECURITY Yes

Roles distinct from security groups Storage of role information

Yes

RACF Database & CICS Transaction Classes

WinHEC 2005 Update - April 20, 2005 Preview Draft

Erro! Estilo no definido. - 11

Factor Access control to system

CICS on MVS z/OS Yes, if RACF protected via RACF Database & CICS Transaction Classes Yes, explicitly programmed, e.g., CICS INQUIRE FILE

Windows Server System Yes, Windows integrated security. Yes, implicit by ACLs on file system directories containing command programs.

Access control on commands

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
Here is some mainframe terminology that may not be familiar to all readers is used in this document: 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. BMS Map A CICS screen layout template, external to the CICS program. 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. 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. SAF - Security Authorization Facility. The mechanism within the MVS operating system which routes security requests to the installed ESM. APPC - Application Program-to-Program Communication. Active Directory the directory with the Windows system where user and other information is stored. ACL Access Control List. NT Service A program automatically stated by the Windows Service Control Manager (SCM). The SCM will only start services if their dependencies are met and the SCM monitors their continue execution. Somewhat analogous to an MVS Started Task. SSO Single sign-on is 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.

WinHEC 2005 Update - April 20, 2005 Preview Draft

Erro! Estilo no definido. - 12

Resources
Software developer information on access authorization in Windows can be found in the Microsoft Platform SDK on MSDN at http://msdn.microsoft.com/library/en-us/dnanchor/html/securityanchor.asp Information on access authorization in Windows relative to RACF can be found at http://msdn.microsoft.com/library/en-us/secauthz/security/authorization_portal.asp. The IBM CICS RACF Security Guide (SC33-1701) at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dfhjat5f/ The CICS System Definition Guide (SC34-5988-01) at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dfha2p07/ The IBM Redbook Securing Web Access to CICS IBM Redbook at http://www.redbooks.ibm.com/redbooks/pdfs/sg245756.pdf A summary of CICS Security, see Securing Web Access to CICS at http://www.redbooks.ibm.com/redbooks/pdfs/sg245756.pdf More information on security in Windows Server 2003 can be found at http://www.microsoft.com/windowsserver2003/technologies/security/ Information for developer regarding security in Windows Platform can be found at http://msdn.microsoft.com/library/en-us/dnanchor/html/securityanchor.asp

WinHEC 2005 Update - April 20, 2005 Preview Draft