Front cover
Designing for
Solution-Based Security on z/OS
A comprehensive overview of z/OS-provided security services
A discussion of z/OS security, Tivoli products, and On Demand
Expert considerations on implementation and use
Patrick Kappeler Rama Ayyar Christian Chateauvieux Arnauld Desprets Gillian Gainsford Pedro Siena Neto Alain Roessle Mohinze Tidjani Mark Womack
ibm.com/redbooks
International Technical Support Organization
Designing for Solution-Based Security on z/OS
October 2008
SG24-7344-00
Note: Before using this information and the product it supports, read the information in “Notices” on page ix.
First Edition (October 2008)
This edition applies to Version 1, Release 9 of z/OS (product number 5694-A01).
© Copyright International Business Machines Corporation 2008. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents
Notices ...... ix Trademarks ...... x
Preface ...... xi The team that wrote this book ...... xi Become a published author ...... xiii Comments welcome...... xiii
Chapter 1. Some security basics - today’s challenges ...... 1 1.1 Heterogeneity everywhere ...... 2 1.2 Security challenges in today’s installations ...... 2 1.2.1 More on installation security policies...... 3 1.2.2 A word about security architecture ...... 4 1.3 The end-to-end security challenges in the on-demand world ...... 4 1.3.1 The concepts of SOA ...... 5 1.3.2 What it means to go to SOA from the security standpoint ...... 5 1.4 Some technical assets for implementing end-to-end security...... 5 1.4.1 A high-level definition of what the required security services are ...... 6 1.4.2 An important set of universally adopted standards ...... 7 1.5 Today’s obstacles to the implementation of end-to-end security ...... 9 1.5.1 Islands of non-standardization ...... 9 1.5.2 The end-to-end accountability problem...... 10 1.5.3 Approaches for possible solutions ...... 10 1.6 The role of the mainframe in a security architecture ...... 11
Chapter 2. System z platform security and certifications ...... 13 2.1 The heritage ...... 14 2.1.1 Synergy between hardware and software...... 14 2.2 Virtualized environments and security ...... 15 2.2.1 Security and virtualization ...... 15 2.2.2 Certification of virtualized environment security ...... 16 2.2.3 z/VM certification...... 17 2.2.4 PR/SM certification ...... 18 2.3 The System z operating system security ...... 18 2.3.1 z/OS ...... 18 2.3.2 z/VM ...... 19 2.3.3 z/VSE ...... 22 2.3.4 Linux for System z ...... 23
Chapter 3. z/OS security services ...... 25 3.1 The overall views ...... 25 3.2 z/OS security services and APIs ...... 27 3.2.1 z/OS Cryptographic Services ...... 27 3.2.2 z/OS Integrated Security Services ...... 29 3.2.3 IBM Tivoli Directory Server for z/OS ...... 31 3.2.4 z/OS Security Level 3 optional feature ...... 35 3.2.5 Security functions in the z/OS Communications Server ...... 36 3.2.6 Communications Server Security Level 3 optional feature ...... 37 3.2.7 Additional product - OpenSSH for z/OS ...... 37
© Copyright IBM Corp. 2008. All rights reserved. iii 3.3 A word on authorized programs and the z/OS APF facility ...... 37 3.4 A word about auditing ...... 38 3.4.1 RACF auditing data...... 38 3.4.2 Syslog daemon (syslogd) ...... 39
Chapter 4. Focusing on the z/OS Security Server (RACF) ...... 41 4.1 What is RACF ...... 41 4.1.1 The RACF infrastructure for identification, authentication, and authorization. . . . 42 4.1.2 Sharing or synchronization of the RACF data base ...... 44 4.2 RACF security functions ...... 44 4.2.1 Identification and authentication ...... 45 4.2.2 User identity mapping for digital certificates ...... 46 4.2.3 User identity mapping for Kerberos tickets ...... 47 4.2.4 Resource access control...... 47 4.2.5 X.509 digital certificate management ...... 49 4.2.6 RACF as a Kerberos user registry ...... 49 4.2.7 Remote security services via the z/OS LDAP server ...... 49 4.2.8 Support of the J2EE security model ...... 50 4.3 RACF auditing...... 51 4.3.1 The RACF auditing infrastructure ...... 51 4.3.2 RACF auditing controls ...... 53 4.3.3 Exploitation of RACF auditing SMF records ...... 56 4.4 Accessing RACF from Java applications ...... 58 4.4.1 Java API for RACF services in the IBM JDK...... 58 4.4.2 Java APIs in z/OS for RACF services...... 58 4.5 Accessing RACF using the LDAP protocol ...... 59 4.5.1 Administering the RACF users and groups through LDAP ...... 60 4.5.2 LDAP Change Log for changes in RACF USER and GROUP profiles and users-to-groups connections ...... 61 4.5.3 RACF Password Enveloping...... 63 4.5.4 RACF remote services at z/OS V1R8...... 64 4.6 Complementing z/OS RACF ...... 69 4.6.1 IBM Tivoli zSecure administration products ...... 70 4.6.2 IBM Tivoli zSecure CICS Toolkit...... 72 4.6.3 Risk and compliance products ...... 73
Chapter 5. A brief reminder about System z integrated hardware cryptography . . . . 79 5.1 Cryptographic function support in System z10 ...... 80 5.2 Overview of the cryptographic devices in System z9 and z10 ...... 80 5.2.1 CP Assist for Cryptographic Functions (CPACF) ...... 80 5.2.2 The Crypto Express 2 Coprocessor (CEX2C)...... 80 5.2.3 Crypto Express 2 Accelerator (CEX2A) mode ...... 82 5.3 Reminder on hardware coprocessors and logical partitioning...... 83 5.4 Reminder about z/OS hardware cryptography infrastructure ...... 83 5.4.1 Reminder about ICSF ...... 84 5.4.2 ICSF releases ...... 86 5.5 Hardware cryptography exploitation on z/VSE ...... 86 5.5.1 RSA acceleration ...... 86 5.5.2 CPACF exploitation...... 86 5.5.3 Infrastructure...... 86
iv Designing for Solution-Based Security on z/OS 5.6 Hardware cryptography exploitation in Linux for System z ...... 87 5.7 Setting up the hardware cryptography configuration of z/VM ...... 88
Chapter 6. Using the LDAP directory as a User Registry ...... 91 6.1 Review of LDAP ...... 92
6.1.1 The LDAP data organization...... 92 6.1.2 Access control in LDAP ...... 94 6.1.3 Using the LDAP directory ...... 95 6.2 Using the z/OS LDAP directory as a user registry ...... 97 6.2.1 Supported SASL mechanisms ...... 98 6.2.2 TDBM- or LDBM-based user registry ...... 98 6.2.3 Using the z/OS SDBM backend for authentication ...... 100 6.2.4 z/OS LDAP auditing ...... 100 6.2.5 z/OS LDAP user registry synchronization...... 100
Chapter 7. Additional considerations about identification, authentication, and authorization services ...... 103 7.1 Identification and authentication service considerations ...... 104 7.1.1 User identity ...... 104 7.1.2 Interoperable identities ...... 104 7.1.3 Identity mapping in z/OS...... 105 7.2 Trusted Third Party authentication ...... 107 7.2.1 The conceptual view ...... 107 7.3 The concept of asserted identity ...... 109 7.4 z/OS and Trusted Third Parties...... 110 7.4.1 Extending the z/OS Trust Domain with TTP authentication technologies...... 110 7.4.2 z/OS as a Trusted Third Party...... 111
Chapter 8. Overview of TCP/IP network security ...... 123 8.1 General discussion - non-secure network threats...... 124 8.2 Network protection and network security zone considerations ...... 125 8.2.1 Common network models - overview ...... 126 8.2.2 Mapping network zones to an organization’s network components ...... 128 8.2.3 Practical design...... 129 8.3 TCP/IP stack hardening ...... 130 8.4 z/OS network protection ...... 131 8.4.1 TCP/IP-oriented additional RACF protections...... 133 8.5 IP Filtering ...... 135 8.6 IPSec virtual private networks ...... 137 8.6.1 IPSec protocols and modes ...... 137 8.6.2 IPSec Security Association and key exchange...... 138 8.6.3 Implementing network communication security with IPSec - IPSec modes . . . . 140 8.6.4 z/OS IPSec characteristics ...... 142 8.7 Application Transparent TLS...... 144 8.7.1 AT-TLS implementation ...... 145 8.7.2 The AT-TLS policy ...... 146 8.7.3 z/OS AT-TLS aware applications ...... 147 8.7.4 z/OS TN3270 server ...... 148 8.8 z/OS IPSec or AT-TLS ...... 148 8.9 Intrusion detection and z/OS Intrusion Detection Services ...... 149 8.9.1 Intrusion detection overview ...... 149 8.9.2 Network-based intrusion detection ...... 150 8.9.3 Host-based intrusion detection ...... 150 8.9.4 z/OS Intrusion Detection Services ...... 151
Contents v 8.10 z/OS IP Security or IDS data collection...... 152 8.10.1 z/OS Syslogd ...... 152 8.10.2 IDS management and alerts ...... 153 8.11 Complementing z/OS network security ...... 153
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 155 9.1 Security environments and WebSphere Application Server for z/OS ...... 156 9.1.1 WebSphere Application Server and z/OS - overview ...... 156 9.1.2 WebSphere Application Server for z/OS communication flows ...... 157 9.1.3 WebSphere Application Server-specific RACF protected resources ...... 159 9.2 WebSphere Application Server user identification and authentication ...... 160 9.2.1 WebSphere Application Server authentication mechanisms ...... 160 9.2.2 WebSphere Application Server user registries ...... 163 9.2.3 Other WebSphere Application Server identity considerations ...... 163 9.2.4 WebSphere Application Server and asserted identity...... 165 9.2.5 Synchronize to OS thread...... 166 9.3 WebSphere Application Server authorization mechanisms ...... 167 9.3.1 Declarative security and programmatic security ...... 168 9.3.2 Using SAF for authentication and authorization - summary ...... 169 9.3.3 Using Java Authorization Contract for Containers (JACC) for authorization. . . . 170 9.4 Using LDAP as a user registry for WebSphere Application Server...... 172 9.4.1 Using z/OS LDAP as a user registry...... 174 9.4.2 Using LDAP authentication and RACF authorization ...... 174 9.4.3 Using z/OS LDAP as an authorization database ...... 175 9.5 Web Services security overview ...... 175 9.5.1 High level architecture for Web Services Security ...... 176 9.5.2 Web Services Security for SOAP Message V1.0 feature overview ...... 180 9.5.3 Using identity assertion with Web services...... 182 9.5.4 Web Services Security implementation in z/OS overview...... 183 9.5.5 Security threats specific to XML SOAP messaging ...... 186 9.6 WebSphere Application Server and auditing ...... 187 9.6.1 Auditing capabilities for WebSphere Application Server for z/OS...... 187 9.6.2 Security auditing service ...... 189 9.6.3 Remote Authorization requests performed via IBMRRAP ...... 189
Chapter 10. Tivoli products that team with the mainframe ...... 191 10.1 The IBM Tivoli security portfolio ...... 192 10.1.1 Tivoli security products that can execute on z/OS ...... 193 10.2 Tivoli security products used in our sample configuration...... 193 10.2.1 IBM Tivoli Access Manager (TAM) ...... 194 10.2.2 IBM Tivoli Directory Integrator (ITDI) ...... 204 10.2.3 IBM Tivoli Identity Manager (ITIM) ...... 210
Chapter 11. Sample configuration - identity provisioning, authentication and authorization ...... 219 11.1 Our sample configuration ...... 220 11.1.1 User populations and user registries...... 221 11.2 Dealing with multiple directories ...... 223 11.2.1 User provisioning and registry synchronization...... 223 11.2.2 User registries...... 225 11.2.3 User registries - synchronization flow ...... 226 11.3 Variations on identification and authorization ...... 228 11.3.1 WebSphere Application Server identification and authentication with LDAP . . 228 vi Designing for Solution-Based Security on z/OS 11.3.2 WebSphere Application Server authorization ...... 230 Related publications ...... 233
IBM Redbooks ...... 233 Other publications ...... 233
Online resources ...... 234 How to get Redbooks...... 234 Help from IBM ...... 234
Index ...... 235
Contents vii
viii Designing for Solution-Based Security on z/OS Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright IBM Corp. 2008. All rights reserved. ix Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:
AIX® MVS™ System z® CICS® NetView® System/370™ DataPower® Notes® Tivoli® DB2® OS/390® VTAM® DFSMS™ Parallel Sysplex® WebSphere® DFSORT™ PR/SM™ z/Architecture® Domino® RACF® z/OS® DRDA® RDN™ z/VM® i5/OS® Redbooks® z/VSE™ IBM® Redbooks (logo) ® z10™ IMS™ RMF™ z9® Language Environment® S/370™ zSeries® Lotus Notes® System z10™ Lotus® System z9®
The following terms are trademarks of other companies:
Novell, SUSE, the Novell logo, and the N logo are registered trademarks of Novell, Inc. in the United States and other countries.
EJB, Enterprise JavaBeans, J2EE, Java, JavaBeans, JavaServer, JDBC, JDK, JMX, JNI, JSP, JVM, Solaris, Sun, Sun Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Active Directory, Authenticode, ESP, Microsoft, Windows NT, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
x Designing for Solution-Based Security on z/OS Preface
This IBM® Redbooks® publication provides solution designers and architects with a comprehensive view of the security services they can exploit on z/OS®, whether their application is hosted by z/OS or by another platform. It also discusses, at a high level, the Tivoli® products that team with mainframe security services to provide flexible and extensible security architectures that fit On Demand infrastructure requirements, because implementing optimum solution-based security requires extensive knowledge of what security services and APIs provide on the platforms for which you are developing the solution.
The book briefly describes data processing security concepts, with a focus on the problems that enterprises face today because of the heterogeneous nature of their platforms and technologies, and the requirement to progress towards an On Demand environment. Next, it explains the security services and APIs that are provided on z/OS, with respect to the security concepts they implement and their seamless integration into distributed environments, as building blocks for optimal solution-based security. This analysis is examined from the perspective of both z/OS solutions and non-z/OS hosted solutions, because non-z/OS hosted solutions can exploit the remote security services that z/OS offers. High level explanations and exploitation considerations are provided for z/OS RACF®, LDAP server, Kerberos and PKI support, z/OS Communications Server-specific features (such as embedded IP filtering, IPSec VPNs, and application-transparent TLS), and many other features.
The path to developing On Demand enterprises requires the development of new applications and security models such as those proposed by Web Services technology. This book explains how z/OS remains a major player in this area, by operating in close synergy with WebSphere® middleware.
Preparing and implementing for On Demand enterprises also places great demands on security infrastructure adaptability and flexibility, and z/OS and Tivoli security products cooperate closely to meet these demands, without jeopardizing existing security standards. The book illustrates, through examples, how this cooperation provides maximum exploitation of the robust security of the z/OS platform, and explores how z/OS building blocks are exploited by IBM middleware such as CICS®, IMS™, DB2® WebSphere Application Server, and Web services to help you achieve your enterprise’s security goals.
The team that wrote this book
This book was produced by a team of specialists from around the world working at the Montpellier European Products and Solutions Center and at the International Technical Support Organization, Poughkeepsie Center.
Patrick Kappeler is a Consulting IT Specialist in Security, and works for both the Montpellier European Products and Solutions Support Center (PSSC) and the International Technical Support Organization (ITSO) Center in Poughkeepsie, USA. He holds a French Air Force Ecole Technique degree in Electronics and Computer Science. Patrick has worked for IBM since 1970, and has held many positions internationally, dealing with mainframe hardware and software technical support and education. For the last 10 years, he has specialized in mainframe e-business security, and writes, presents, and consults extensively on this topic throughout the world.
© Copyright IBM Corp. 2008. All rights reserved. xi Rama Ayyar is a Senior IT Specialist with the IBM Support Center in Sydney, Australia, and has more than 25 years of experience with the MVS™ Operating System. His areas of expertise include TCP/IP, RACF, DFSMS™, z/OS Operating System, Configuration Management, Dump Analysis, and Disaster Recovery, and he has co-authored six IBM Redbooks publications. Rama holds a Master's degree in Computer Science from the Indian
Institute of Technology, Kanpur, and has worked in IT for the past 35 years.
Christian Chateauvieux works on the Tivoli Security technical sales team in France and Northwest Africa, focusing on pre-sales related to the Tivoli Security portfolio. His areas of expertise include IBM Tivoli Directory Integrator, IBM Tivoli Directory Server products, and IBM Tivoli Security Compliance Manager, and Tivoli Security solutions related to Identity Management, Meta-directories, Data Synchronization, and Access Control. Christian holds a Master of Science degree in Computer Sciences from the Institut National des Sciences Appliquées (INSA), Toulouse, France.
Arnauld Desprets is an IT Architect with IBM Software Services for WebSphere in the UK, who has more than 10 years of consulting experience with companies throughout Europe. He also has more than eight years of experience with WebSphere Application Server, and now specializes in SOA and Web services, especially in WS-Security. Arnauld’s current area of interest involves the role of governance and the registry, including the WebSphere Services Registry and Repository in an SOA.
Gillian Gainsford has worked for IBM New Zealand for nine years, and has 25 years of experience in mainframe system programming. Currently, she is a Security Program Manager for Audit Compliance and Risk Management. Previously, she was a Security Systems Programmer for IBM Global Services. Her area of expertise is compliance and security of z/OS systems, using both RACF and CA-ACF2 and the inherent security features of z/OS and its subsystems. Before joining IBM, Gillian worked as a mainframe system programmer and Technical Support Manager in the airline, banking, and manufacturing industries. She holds a Bachelor of Arts Degree from Auckland University.
Alain Roessle is a Certified IT Specialist and has worked in the European Design Center for eight years. He joined IBM in 2000 after a 20-year career as a System Engineer, mainly specializing in System z®. Alain’s current job responsibility involves helping customers to design SOA infrastructure solutions.
Pedro Siena Neto has been Chief Executive Officer and Chief Architect of SST It Solutions, Brazil, since 1996. SST is an IBM Business Partner focused on business process management (BPM), software oriented architecture (SOA), IT security services, and mobile solutions. He holds a Master’s degree in Business Administration (MBA) from Fundação Getúlio Vargas, and Ohio University, and has worked in IT since1987. Previously, Pedro worked at IBM Brazil and IBM Research Triangle Park, NC as a 37XX Communication Controller Product Engineer, a WLAN Developer, a TCP/IP Software Specialist, and an IT Services Architect.
Mohinze Tidjani has been with IBM since 2000. He is an IT Specialist for IBM Software Group Services with EMEA-WEST, specializing in IBM Tivoli Directories and Security core products including ITAM 6.0, TFIM6.0, ITIM 4.6, ITDS 6.0, and ITDI 6.0. Mohinze is certified on IBM Tivoli Identity Manager and Access Manager deployment, and is currently “IMT France” Security Practice Leader. Mark Womack is a Staff Software Engineer at the Programming Labs in Research Triangle Park. He has 23 years of experience with IBM, providing IT support for products such as VTAM®, TCP/IP, and most recently WebSphere MQ, for which Mark is a Certified System Administrator.
Thanks to the following people for their contributions to this project: xii Designing for Solution-Based Security on z/OS Paola Bari, Robert Haimowitz, Richard M. Conway, David Bennin and Roy Costa ITSO Poughkeepsie Center
Axel Buecker, ITSO Tivoli Security Project Manager ITSO Austin Center
Arthur Fitzpatrick, Security Design and Development IBM Poughkeepsie
Richard Guski, STSM zSeries® Software Security Architecture IBM Poughkeepsie
Bruce Wells, RACF Development Software Designer IBM Poughkeepsie
Deborah Mapes, RACF Design Software Designer IBM Poughkeepsie
Timothy Hahn, Tivoli Chief Architect, Secure Systems and Networks IBM Durham
Johan Varno, IBM Tivoli Directory Integrator Lead Architect IBM Norway
William J. O’Donnell, IBM Software Group, WebSphere Security Architect - Security Development IBM Madison
Hyen-Vui (Henry) Chung, IBM Software Group, Web Service Security Development IBM Austin
Become a published author
Join us for a two- to six-week residency program! Help write a book dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You will have the opportunity to team with IBM technical professionals, Business Partners, and Clients.
Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you will develop a network of contacts in IBM development labs, and increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about this book or other IBM Redbooks publications in one of the following ways: Use the online Contact us review Redbooks form found at:
Preface xiii ibm.com/redbooks Send your comments in an e-mail to: [email protected] Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400
xiv Designing for Solution-Based Security on z/OS
1
Chapter 1. Some security basics - today’s challenges
In this chapter some basic security concepts and what the users expectations are when implementing nowadays security services and policies. This is put in perspective of today’s installations which are mostly composed of heterogeneous systems, and the specific challenges that result from this situation when it comes to implement security at the installation, or across installations, level.
We are using in this chapter the terms “installation” and “organization” somehow interchangeably. They both designate the same entity, with “organization” used to address the abstract level of goals and procedures the entity’s members have to abide by, whereas “installation” rather refers to the set of technologies, and the organization members assigned to their operations, that serve meeting the organization’s goals and procedures.
© Copyright IBM Corp. 2008. All rights reserved. 1 1.1 Heterogeneity everywhere
Most data processing installations today are composed of heterogeneous platforms that exploit different data processing systems, each with its own model of operations and supporting operating system. The users expect these systems to interoperate seamlessly and provide the set of resources required to serve their requests.
This situation results, in the majority of cases, in an attempt by these installations to optimize the level of service they can get out of these platforms, taking into account, for example: Their cost of ownership and/or of operation The level of skills they require to operate and maintain Their reliability and availability
Users have also understood over the years the paramount importance of having proper assets protection, and they expect today from any service implementation, whatever system or mix of systems it performs on, the following: To proceed with identification and authentication of the users. To control access to protected assets, on the basis of a user’s identity and the privileges granted to this identity, as specified in access rules that may apply far beyond a single system. To implement confidentiality and integrity of the data. To provide, whenever required, an audit trail of security events.
Note that there can be variations in the above requirements, such as, for example, users that can be identified as “anonymous” by some applications. Also, authentication makes sense only when there is a real need to ascertain the user identity, as is the case when users have to access protected resources.
At the organization level, what is “proper” security is specified in security policies. These specifications are usually a trade-off between the cost of implementing security measures and the risks that are actually incurred should assets be affected by a security breach.
Enforcing the security policies requires many layers in the implementation, the layers closest to the systems obviously providing technology-enforced policies. Systems from laptops to large mainframes provide their own implementation of security mechanisms that contribute to meeting the users’ expectations.
However, at the system level, this is purely local and partial coverage of pieces of a security policy. Technology should also provide a means to federate these local actions so that the users’ requests are performed with respect to the policies defined at the organization level, across all the systems explicitly or implicitly involved in serving these requests.
1.2 Security challenges in today’s installations
The security challenges lie precisely in this heterogeneity that is one of the most prevalent characteristics of today’s installations.
There is here a strong need for integration so that process flows that serve the users’ requests are smoothly executed across systems whose technologies differ in many points. Process flows are supported by configurations such as the simple and well known client-server configurations, up to a multi-tier version of this configuration. Typically, a multi-tier configuration is composed of a small system, most of the time well-adapted to support a user graphical interface, that interacts directly with the end users and propagates
2 Designing for Solution-Based Security on z/OS the users’ requests to a downstream system, generally more powerful and more efficient in running applications with heavy computational requirements. Finally, this application server system relies itself on a downstream mainframe for high volume data movements with secure and high performance data repositories. Again, this staged approach is a result of the search for best performance and economical trade-offs when implementing the process flow.
In these configurations the user is not aware of which systems are participating in the execution of the request. The technology has to unify the behavior of all the involved systems so that the user is guaranteed that the organization security policy is being enforced in all the steps it takes to execute the request. In other words, the user expectation is to deal with an implementation of “end-to-end” security, meaning that any security directives expressed in the security policy that applies to the end-user request are enforced all along the process chain involved in serving this request, whatever the number and nature of the implementation layers and systems involved.
This definition also addresses the privileges granted to the authenticated identity of the end user, and its accountability in any security event recorded along the request-serving process chain.
1.2.1 More on installation security policies
The goal of the security policies is to address the potential threats an installation can be exposed to and how they should be handled. Note that most of the time, a policy has to be implemented for an already existing environment and must be adapted to consider the existing base of: Assets and applications Equipment in use and its connectivity Procedures and practices Roles and responsibilities Installation personnel and possible partners Potential threats and adversaries
An installation usually defines many security policies, covering specific processes, such as: Responsibility Policy Asset Classification Policy Threat Assessment Policy – Frequency of assessment – Assessment methodology Trust Policy – Accepted authorities – Certification prerequisites Privilege Policy – Role definitions Regulatory Compliance Policy –Privacy – Records retention – Business practices Access Policy – Physical access – Logical access – Authorization – Data protection Accountability Policy –Audit
Chapter 1. Some security basics - today’s challenges 3 – Non-repudiation The security policies are expected to specify what the countermeasures are for each important threat. These countermeasures can be non technology-related, for example checking the background of applicant personnel, displaying identification tags, physical security of laptops, etc. There are also technical countermeasures that specifically address threats such as: Impersonation of user Impersonation of service Modification of program Modification of data Disclosure of data contents
Last, but not least, security policies are enforced in a geographically delimited perimeter called the policy domain, meaning that all entities located in the security domain should abide by the security policy and are expected to be provided with the means to do so.
Important: At some point in time, when specifying security policies, there is always the need to rely on the notion of trust. That is, an assumption has to be made, and considered always to be true as long as the policy exists, that specifically designated entities are trustworthy, without requiring further proof of their trustworthiness.
Note also that trust, in many implementations of security policies and services, can be transitive, meaning that trusted entities can vouch for the trustworthiness of other entities, implicitly extending the domain of trust to incorporate these other entities.
We further discuss the domains of trust and how they can be expanded in Chapter 7, “Additional considerations about identification, authentication, and authorization services” on page 103.
1.2.2 A word about security architecture
The technical countermeasures against policy-specified threats are expected to be enforced by technology. However, there is no such thing today as a single product that can provide at once all the technical countermeasures an installation may need, and one should not expect such a product to become available in the foreseeable future. A security architecture should be put in place in order to implement these technical countermeasures in an integrated way. A security architecture defines the following: The components that are required to properly implement the countermeasures The interfaces to these components The protocols used for communication between the components The conceptual view of each component’s individual tasks and its interrelationships with the other components in the architecture
1.3 The end-to-end security challenges in the on-demand world
We have introduced our previous considerations on security policy and security architecture implementations as stemming from the intrinsic heterogeneity of today’s installations. Actually, the matter is getting much more complicated as we enter the on-demand era, where computing services have to become even more “dematerialized” with respect to the physical infrastructure they run on. This physical infrastructure itself might dynamically change from request to request, on the basis of the nature of the request and/or the resources available to
4 Designing for Solution-Based Security on z/OS serve it at the time it is issued. The request process flow therefore must cross physical, technological and organizational boundaries in order to exploit the required and available resources. But the users still have to keep an abstract and stable view of this dynamically reshaping environment, and must be assured of the proper respect for the security policies they abide by, and of a consistent implementation of end-to-end security in the processes they are starting.
1.3.1 The concepts of SOA
The Service-Oriented Architecture addresses services to be provided to users, as opposed to focusing on the technology of the systems these services will be performed by. Services can be self-contained functions that do not depend on the context or state of other services, but in the vast majority of cases services can be thought of as loosely-coupled entities that communicate with each other, because the user requests may have to be served by collections of multiple services. The inter-service communications are to carry user data, security related information, and service coordination data.
Web Services are a set of technologies that fulfill the requirements for connecting services, operating at an abstraction layer high enough not to be sensible to the constraints of the various underlying system technologies. As an example of this interoperability-oriented abstraction level, XML messaging is used to convey the inter-services communications that we describe above.
1.3.2 What it means to go to SOA from the security standpoint
Today, with the implementation of the SOA concepts, many distinct installations may be involved in providing services to a user, each one with its specific technology assets, and quite importantly each with an already established set of security policies and a security infrastructure in place. As already mentioned, which installation is going to be actually involved in providing the services is not known in advance by the users because the routing of the service requests to eventually reach the proper service providers depends on many factors, the combination of which is not predictable.
It is, however, expected that users can keep a single and uniform view of a security policy being enforced all along the physical path followed by the request and its response.This requires the security policy to be specified at the service abstraction level, with an SOA implementation that insures that lower infrastructure layers do enforce this abstract policy.
We discuss Web Services security in 9.5, “Web Services security overview” on page 175.
1.4 Some technical assets for implementing end-to-end security
The computer industry is approaching the end-to-end security challenge in an on demand world by obviously relying on the work experience of data processing security acquired over the past decades, that is, what has been learned over these years and what common understanding of security goals and required mechanisms users agreed upon. This working experience translates today into a very large set of specifications and standards.
Chapter 1. Some security basics - today’s challenges 5 1.4.1 A high-level definition of what the required security services are
The well known ISO 7498-2 standard provides a definition of what services are required to implement security in a data processing environment. This definition applies very well to what we can see implemented today in most of the platforms being used in the industry, with some variations in the effectiveness of the different implementations. These requirements still fit, at an abstract level, the basic security requirements of the on demand world.
In this book we have isolated the following fundamental security services in the ISO 7498-2 standard, which we illustrate and complement here with our own words and usage considerations.
Note that we are using the term end user in the following sections to designate a calling or initiating entity, be it a human being or a software program.
User identification and authentication This service enables an application to verify the end user-provided identity as being known and registered in a policy-designated user registry, and to validate the end user-provided proof of identity as per a policy-designated challenge and authentication mechanism.
As we mentioned previously, policies may admit that in some cases the identity is not needed (“anonymous” users), or that authentication is not required (that would be the case if the installation wants to keep track of who called the system but provides access to public data only).
A user registry can be thought of as a data repository that applications have been directed to accept as a source of valid registered identities. A user registry may also contain authentication data to be used when assessing the proof of identity provided by the calling entity. We will see later what such a user registry might be in today’s installations.
Important concepts related to authentication: It often happens that the systems serving the request are not the systems that the user provided the authentication data to. Two kinds of implementation can then be used to carry over an already authenticated identity from system to system: Implementations based on the use of authentication mechanisms supporting delegation, that is, the intermediate system has to provide valid and verifiable authentication data on behalf of the requesting end user. Implementations based on identity assertion. With identity assertion there is no authentication data carried over once the authentication has been performed by one system. Instead, the authenticating system propagates the user identity only and the other systems assume this identity to have been properly authenticated, on the basis of the trust they have been set up to have in the authenticating system. The use of identity assertion requires secure communications between the authenticating system and the systems receiving the asserted user identity, so that the latter can ensure they are receiving this identity, unmodified, from the expected and trusted system.
Access control Access control is the service by which a user request for accessing a resource is submitted to checking for proper authorization, generally on the basis of the authenticated identity associated with the request. When enforced, access control is then considered “authorization.”
6 Designing for Solution-Based Security on z/OS The authorization rules are specified in an access control data base and are enforced by the authorization service. It is expected that resource owners or security administrators are in charge of maintaining the authorization rules in the access control database, according to a well-defined security policy.
Notes on authorization: It is quite common in some installations not to use the authenticated identity for authorization checking, but instead use a so-called “generic identity,” because this does not relate to a specific user. The key point here is that the authenticated identity is, however, kept in the audit trail so that the request can be traced up to the initiating end user. Authorization is most of the time implemented in two pieces: the access control database and its manager piece, which provides “advice” based on the access control rules it holds on whether the requesting end user should be permitted access or not to the requested resources; and a “resource manager” piece which is to enforce this advice by giving or denying the resource access to the user. Practically, the user request goes to the resource manager, which then consults the access control database manager.
Data confidentiality Data confidentiality is a service intended to render data un-understandable for nonauthorized users. Data confidentiality differs from access control in that the data may be accessible but its meaning is hidden from any user who does not know, or does not have, the way to recover it. Typically, data confidentiality is achieved using encryption.
Data integrity Data integrity is a service to detect unauthorized, or accidental, modification to data. Typically, data integrity is achieved by associating a verifiable checksum, or hash value, to the data. Note that today’s hash algorithms are designed using techniques similar to the design of cryptographic algorithms to insure that they properly meet the users’ expectations in terms of security characteristics.
Auditing Auditing is the service that permanently maintains an audit trail of security-relevant events. A security-relevant event can be defined as an action taken that reflects adhesion to or violation of a security policy in place in a system. The audit trail is to provide historical data that can be used for the purpose of detecting precise actions (and their originators), or trends in actions, that diverge from or can potentially lead to divergence from the security policy.
A note on the use of cryptography: The use of cryptographic techniques today goes far beyond the well-known data confidentiality service. The authentication and data integrity services are also heavy users of cryptographic techniques.
1.4.2 An important set of universally adopted standards
It is obvious that platform and product interoperability in today’s heterogeneous world can be achieved only by supporting commonly adopted standards for communication protocols and data formats. Likewise, portability of applications that use specific security services requires the commonly adopted APIs for these services to be implemented on the various platforms that are candidates for hosting these applications.
Chapter 1. Some security basics - today’s challenges 7 To name a few well-known and widely implemented standards: LDAP (Lightweight Directory Access Protocol) LDAP addresses both the structure and format of data kept in a repository and the client-server protocol to be used to access this data. LDAP is itself derived from the X.500 standards, written in the 1980s to address both data format, repository structures, and access protocols to network-accessible repositories. The LDAP protocol is implemented on TCP/IP only. LDAP in itself does not address security functions beyond the authentication of the directory users and their authorization to use the directory data. However, LDAP is linked to installation security in several ways: many systems today, for instance, are using an LDAP directory for their user registry, and in some cases for their authorization rules data base. Many RFCs have been issued that pertain to the LDAP operations and data formats, among them RFC 2251 and RFC 3377 address the Lightweight Directory Access protocol V3, and RFC 1823 addresses the LDAP client API. X.509 The X.509 standards are in use today to describe the format of digital certificates and certificate revocation lists, and how they should be used in the context of a Public Key Infrastructure (PKI). Since 1995, the PKIX IETF working group is providing widely adopted RFCs related to the miscellaneous issues being faced when operating Public Key Infrastructures where X.509 digital certificates are used. The use of digital certificates entails the use of cryptographic algorithms, because certificates carry an asymmetric public key. Certificates are in use today in many secure protocols where cryptographic processes are involved, for instance, in strong user authentication or data integrity checking. RFC 2459 specifies the use of X.509 digital certificates and certificate revocation lists in a PKIX Public Key Infrastructure. SSL and TLS Secure Socket Layer is a secure protocol originally developed by the Netscape Company in the early 1990s. It protects TCP sockets-based communication using cryptographic techniques for the authentication of the communicating parties, and the integrity and confidentiality of the transferred data. SSL has been stabilized at the SSL V3 level since 1996. As of today, SSL is superseded when designing new applications by Transport Layer Security (TLS). TLS can be thought of as an IETF standardized version of SSL, with specific improvements. Note, however, that although SSL and TLS are not compatible protocols, the vast majority of today’s TLS-enabled applications are designed to fall back to SSL if the communicating partner only supports SSL. TLS is specified in RFC 2246. Kerberos Kerberos is an authentication protocol intended for authentication of clients and servers in a non-secure TCP/IP network. Kerberos is based on the use of symmetric cryptography, as opposed to SSL/TLS, which uses asymmetric algorithms. Optionally, the Kerberos protocol can also provide cryptographic session keys that applications use for data confidentiality and integrity. Kerberos is described in RFC 1510. IPSec
8 Designing for Solution-Based Security on z/OS IPSec, for Internet Protocol Security, is a secure protocol used to protect any stream of IP packets transferred between two TCP/IP stacks. As for SSL/TLS, the protection is based on the use of cryptographic techniques for mutual authentication of the communicating parties, and confidentiality and integrity of the exchanged data. Note, however, that the IPSec protocol is performed by the TCP/IP stack at the network layer, whereas SSL/TLS is
performed by the application at the transport layer. The IPSec specifications are covered by many RFCs, mainly the RFC 2401 to RFC 2410 series. Cryptographic algorithms The secure protocols mentioned above exploit cryptographic processes and cryptographic algorithms. Their interoperability also depends on the use of public and commonly adopted algorithms. Examples of well-known public algorithms are: – Data Encryption Standard ()DES) is a symmetric algorithm developed in the 1970s, and is heavily used in the Industry. However, the key length of DES (56 bits) is deemed today, with respect to the current state of the art in computer technologies, to be too short to offer proper protection of data. Users have been encouraged for the past few years to migrate to Triple-DES, which uses keys of 112 bits or 168 bits. – Advanced Encryption Standard (AES) has been designated as the successor of DES and Triple-DES. It is a symmetric algorithm that operates with key lengths of 128, 192 or 256 bits. Triple-DES users are progressively shifting today to the use of AES. – Rivest - Shamir - Adleman (RSA) is an asymmetric algorithm that can be used to encrypt or sign data. RSA works with key lengths such as 512 bits, 768 bits, 1024 bits, 2048 bits and 4096 bits. RSA is the archetype of asymmetric algorithms and is widely in use today, in particular with the SSL/TLS protocols. – Message Digest 5 (MD5) and Secure Hash Algorithm (SHA) are hash algorithms that are used for data integrity checking and digital signature. MD5 yields a hash value of a fixed length of 128 bits, SHA comes with different lengths of the hash value: 160, 224, 256, 384 or 512 bits. The current terminology designates the 160-bit hash value algorithm as SHA-1, while all the other hash lengths are comprised in the generic SHA-2 designation. Web Services security is specified in a more recent series of standards that we discuss in 9.5, “Web Services security overview” on page 175.
1.5 Today’s obstacles to the implementation of end-to-end security
Despite the rich set of common standards adopted by the Information Technology vendor community, there are still pieces of security-related information that cannot be properly exchanged between systems, and this situation can therefore jeopardize proper implementation of end-to-end security. Here we address, at a high level, the reasons for such a situation and what the current approaches are to solve the potential problems.
1.5.1 Islands of non-standardization
We are in a situation today where the implementation of security models among data processing systems is not standardized among the varilous vendors. For example, there is no common standard to specify what the length of a user ID or a password should be in a system user registry, or what syntax to use to define an access control list in the authorization data base. Actually, if vendors were required today to standardize such items, this would lead to
Chapter 1. Some security basics - today’s challenges 9 envision a drastic redesign of all existing data processing systems and the applications they host. For obvious reasons, one cannot expect this to happen in the foreseeable future.
The same situation exists at a higher level with specific conventions or local standards developed by installations for applications that differ from conventions and local standards developed at other installations.
As a result, two systems or applications may have to exchange data, semantically identical for both parties, but expressed in non-compatible format and syntax. In other words, the systems may interoperate at the data transport level using the same standardized protocols, but the very contents of this data may happen not to be usable at the receiving end, due to specific conventions or local standards which are not shared between the two communicating parties. As for the data processing system example above, one cannot realistically expect a uniformization of such conventions and local standards.
1.5.2 The end-to-end accountability problem
End-to-end security implicitly requires end-to-end accountability, meaning that at any time during the execution of the chain of processes that serve an end-user request, the identity of the initial requestor is known and is properly indicated in the auditing trail of the security events that may occur at any stage of execution of these processes.
However, one has to admit that many installations today are in a situation where the initial requestor identity cannot be propagated.
Non-propagation of security information It is quite common today to find applications that do not propagate the requestor’s identity to downstream systems. The reasons for doing so vary from the application design which does not provide any propagation capability, to the sheer fact that the identity is meaningless to the downstream system. The latter case itself can be the result of many different situations: the identity is not registered in the downstream system or the identity syntax model of the downstream system is not compatible.
Usually the walk-around to this situation is to have the upstream application calling the downstream one using a generic user identity that the latter recognizes. In that case, however, all requests are passed using the same generic user ID, which might be the identity that appears in the auditing trail resulting in the loss of the initial requestor identity. Furthermore, using a generic user ID does not allow to establish granular access control because, by definition, all required access permissions have to be given to the same single user ID.
Note, however, that as already mentioned, generic identities are widely in use today and it is important to have, at least, proper tracking of the initial requestor’s identity in the audit trail.
1.5.3 Approaches for possible solutions
In many cases there is nothing that can be done for applications that by design do not forward security information—except, maybe, by changing these applications. When facing the islands of standardization problem, there are roughly three mechanisms that can possibly establish some kind of mediation between incompatible conventions or local standards: Information mapping Information federation
10 Designing for Solution-Based Security on z/OS Sharing of security policy and service repositories A mix of the above mechanisms
Information mapping Information mapping is the mechanism whereby the nature of a piece of information is preserved, for instance a user ID, but the contents are replaced (mapped-to) in order to be usable by the receiving system.
An example of such a service would be the mapping of an X.500 name in a digital certificate to a local system user ID, for instance to a RACF user ID. From the implementation standpoint these mapping mechanisms can be implemented inside the receiving operating systems or applications, or can be provided as externally provided services.
This mechanism solves the syntax and format incompatibilities problem. However, security administrators at the installation or application level have to understand and maintain the mapping criterias that consistently tie the input and output information together. As a consequence, the trustworthiness of the mapping information relies mainly on the way administrators perform their task.
Information federation Information federation is an abstract term. It addresses an infrastructure made of mechanisms that insure that conveyed information remains understandable and usable by recipients, and can be dynamically validated for authenticity by authorized and trusted servers located in the federated infrastructure. The information federation infrastructure often provides mapping mechanisms to compensate for the disparity of conventions and local standards between the participating systems, and the goal of the infrastructure is to automate this mapping so that it is transparent to the receiving applications.
The benefit of information federation relies precisely on the low impact to the existing set of applications of all partners in the federation. However, it necessitates the infrastructure implementing highly trusted communication channels that guarantee the trustworthiness of the received information to the recipient.
Security policies and services hosted by an external device In this approach, operating systems or applications are provided with an API to access an external device that manages security policies and provides security services. The point here is that this API is made available to several different platforms and they all access the external device, which then becomes a de-facto commonly adopted policies repository. This allows for sharing of single instances of policies among systems of different technologies.
An example of implementation of this concept is the IBM Tivoli Access Manager, which provides means of sharing access control policies between disparate systems, provided these systems implement the Open Group aznAPI authorization API.
1.6 The role of the mainframe in a security architecture
The applications running in System z are obviously consumers of security services. These services are provided by the operating system (z/OS, z/VSE™, or Linux®) itself or by runtime environments created by middleware such as WebSphere Application Server.
However, System z can also act as a security services provider to other platforms in an installation. We give details about these z/OS-provided security service implementations in
Chapter 1. Some security basics - today’s challenges 11 Chapter 3, “z/OS security services” on page 25. Just to name a few of these System z provided services: LDAP directory services These services can be hosted by Linux for System z or z/OS. In the z/OS case the LDAP protocol is also extensively used to provide remote access to other services besides the simple data repository service. Note that LDAP services are also implemented in z/VM®, starting with z/VM 5.3. X.509 (PKIX) Certificate Authority There are today on the market Certificate Authority software products that can be hosted by Linux for System z. z/OS comes with a complete set of Certificate Authority functions: the z/OS PKI Services, which can be used to provide Certificate Authority services within one organization or across several organizations. Kerberos Key Distribution Center (KDC) Likewise, there are Kerberos KDC products on the market that can be hosted by Linux for System z. Again, z/OS comes with an imbedded Kerberos KDC support: the z/OS Network Authentication Service. z/OS can therefore provide Kerberos tickets to any platform that supports the Kerberos V5 protocol.
Giving more focus to the z/OS example: these services are provided as standard features in z/OS, meaning that it is up to the user to decide to use them or not. Providing these services from a z/OS system lets the users benefit from the platform’s intrinsic reliability and security features.
12 Designing for Solution-Based Security on z/OS
2
Chapter 2. System z platform security and certifications
In this chapter we describe how the System z infrastructure contributes to the intrinsic security of the platform.
© Copyright IBM Corp. 2008. All rights reserved. 13 2.1 The heritage
System z benefits from several decades of experience in designing systems, keeping in view the best possible synergy between hardware and software. These systems have been designed to host a very large number of concurrent users and executing programs in a very secure manner, with the capability of providing network access in presumably hostile environments.
Customer feedbacks on security-relevant problems experienced with these systems have been formally encouraged through the IBM Statements of Integrity for the operating systems for the past 35 years.
2.1.1 Synergy between hardware and software
System z benefits from the experience acquired over the years with implementation of the principles that were driving the initial design of System 360, in the early 1960s, as follows: Providing services to several users with very robust isolation between the data of different users and between the users’ applications and the operating system Providing a high level of resilience and availability of the platform that could guarantee consistently viable operations of the security functions Meeting these objectives by achieving the best possible synergy between hardware and software
Altogether this led to the implementation of the following features, which are described in detail in z/Architecture Principles of Operation, SA22-7832.
Privileged and general instructions Privileged instructions have the capability to affect the user execution environment, and they are only available to the operating system. Privileged instructions deal with many aspects of the users’ private execution environment management, such as: Memory allocation and access control to the memory Data transfer between the system memory and external devices User program execution and resumption
General instructions (also termed problem-state instructions) can be executed by any program, operating system, or user application, and only deal with data and environments that are private to the executing program.
The hardware interruption mechanism With this mechanism the system’s hardware monitors specific conditions and, when such a condition is met, interrupts the execution of a user program to give control to the operating system.
One such condition might be the behavior of a user program that would otherwise have resulted in accessing other users’, or operating systems’, private data. Another condition for generating a hardware interruption is the hardware detection of a malfunction in the system.
14 Designing for Solution-Based Security on z/OS Storage protection Four protection facilities are provided in the system’s hardware to protect the contents of main storage from destruction or misuse by programs that contain errors or are not authorized to the protected storage area: Key-controlled protection Address space access-list-controlled protection Page protection Low-address protection
The protection facilities are applied independently; access to main storage is only permitted when none of these facilities prohibits the access.
Storage protection is also indirectly enforced using the hardware architected mechanisms for support of virtual storage, such as dynamic address translation tables, because they also participate in the isolation between users and users, and users and operating systems.
The migration of software functions into hardware implementation Over the years, many operating system functions have been migrated from a purely software implementation to a hybrid hardware and software implementation. Some examples of such significant migrations are: The Start Interpretive Execution function (SIE), for hardware-assisted virtualization of the VM operating system guest environments. The Enterprise System Architecture (ESA) set of functions, for the hardware-assisted management of the MVS operating system address spaces.
These changes contribute to the improvement of system performance for these complex and high-overhead functions. They also contribute to enhancing the security of the system by keeping these critical functions away from any unintended or malicious interference that could occur at the software level.
2.2 Virtualized environments and security
System z also has a rich history regarding the virtualization of execution environments, with the availability of the VM operating system (also called an “hypervisor”) in the early 1970s and the Processor Resource/System Manager (PR/SM™) hardware feature in the late 1980s. Eventually, both supports converged to exploit the same hardware-based mechanisms for VM SIE and PR/SM.
2.2.1 Security and virtualization
The virtualization mechanisms have to meet security objectives similar to those of operating systems but specifically addressing the management of virtualized environments.
Important: The security approach for both kinds of virtualized environments on System z (via z/VM or PR/SM) is that the operating system executing in the virtualized environment takes care of the security of its users and their applications and data—this would occur in any real system. The virtualized environment security requirements, as described here, are met by the system’s virtualization mechanism.
Chapter 2. System z platform security and certifications 15 Identification and authentication Each virtualized environment is uniquely identified. The identifier is used for access control to the system resources intended to be exploited in the virtual environment.
Authorized administration and operations Access to configuration information, environment activation, and resource allocation is controlled.
Audit and accountability All security-relevant events related to the management of the virtualized environments are recorded in protected audit logs, which cannot be accessed from guest applications running in a virtualized environment.
Access control to system resources Access to system resources is controlled on a virtual environment basis according to access rules established by the administrator in charge of defining the virtualized environments.
Virtualized environment isolation and separation Virtualized environments are isolated so that a program cannot send a message to or access a resource that is not explicitly allocated to the environment the program runs in. Resources can be dedicated to a virtualized environment and are therefore never shared with other virtualized environments.
The virtualized environments are also separated in that a system or software failure that occurs in one virtualized environment is handled for recovery first in that environment. Only critical hosting system-wide failure conditions may also affect other active environments.
Object reuse Objects, or resources, to be allocated to a virtualized environment are cleared of any residual information before being allocated. Examples of this mechanism are: Storage, which is cleared prior to allocation or reallocation. All information in sharable physical processors or coprocessors that is reset before dispatching any virtualized environment on these units. Non-shared channel paths and attached I/O devices that are reset prior to allocation to a virtualized environment
Reliability of service The system should protect resources allocated to a virtualized environment from denial of service conditions that would affect other environments.
2.2.2 Certification of virtualized environment security
IBM adheres to ISO 15408, also known as “Common Criteria” for the certification of the virtualized environment security. ISO 15408 is the successor to the prior TCSEC and ITSEC standards, and Figure 2-1 on page 17 shows a comparison of the certification levels addressed by ISO 15408 and the previous standards.
16 Designing for Solution-Based Security on z/OS
Common Criteria US TCSEC European ITSEC
EAL1: Functionally Tested D: Minimal Protection E0 EAL2: Structurally Tested EAL3: Methodically Tested and C1: Discretionary Security E1 Checked EAL4: Methodically Designed, C2: Controlled Access E2 tested and reviewed EAL5: Semiformally Designed B1: Labeled Security E3 and Tested B2: Structured Protection E4 EAL6: Semiformally Verified Design and Tested B3: Structured Domains E5 EAL7: Formally Verified Design A1: Verified Design E6 and Tested Figure 2-1 ISO 15408 and TCSEC and ITSEC
An ISO15408 certification is performed by a mandated independent laboratory which tests a product (the “Target of Evaluation” TOE) against an implementation-independent set of security objectives and requirements that have been designed to meet consumer needs for IT security. These requirements are the “protection profiles”. Examples of well-known protection profiles used to assess access control implementation in software products are the Controlled Access Protection Profile (CAPP) and the Labelled Security Protection Profile (LSPP).
The evaluation process itself is performed using a Security Target (ST), that is, a set of security requirements and specifications that address the specific TOE.
Depending on how well the TOE meets the user requirements expressed in the protection profiles, it is assigned an Evaluation Assurance Level (EAL), ranging from EAL 1 to EAL 7. Note that an EAL does not, therefore, mean anything by itself—one must know the contents of the protection profile that was used when meeting this level of evaluation.
Mutual recognition arrangement (MRA) As of today, not all countries recognize an EAL which has been assessed in another country-independent laboratory. A Common Criteria - Mutual Recognition Arrangement (CC-MRA) has been signed for up to EAL 4 between the following countries: Australia, New Zealand, Austria, Canada, Finland, France, Germany, Greece, Israel, Italy, The Netherlands, Norway, Spain, Sweden, UK, and USA.
With the consequence that an EAL greater than 4 is not going to be recognized by these countries for any evaluation performed in a foreign country (in that case the EAL remains at 4 in these countries), with the exception of European countries that mutually recognize EALs up to 7 for evaluations performed in Europe.
Note: Pointers to the formal security evaluations of IBM products can be found at: http://www.ibm.com/security/standards/st_evaluations.shtml.
2.2.3 z/VM certification
z/VM Version 5.1 completed the ISO 15408 evaluation in October 2005, with EAL 3+. The ST included CP, the TCP/IP stack with Telnet, and RACF/VM. The identification, authentication of VM users, and access control to the system resources was achieved using RACF and the following protection profiles:
Chapter 2. System z platform security and certifications 17 Labeled Security Protection Profile (LSPP) - For Mandatory Access Control to enforce security levels and compartmentalization of users and resources Controlled Access Protection Profile (CAPP) - To control user or administrator access via Discretionary Access Control
As of the writing of this book, the decision has been made by IBM not to certify z/VM Version 5.2, instead z/VM version 5.3 goes under evaluation for CAPP/LSPP at EAL 4+.
2.2.4 PR/SM certification
The PR/SM feature of System z also went under ISO-15408 certification. It was granted EAL 5 on System z9®, by an independent German laboratory. As per the terms of the CC-MRA above, it is recognized as being EAL 4 only in non-European countries.
PR/SM was evaluated using a specific Security Target and was not covered by standardized protection profiles. The PR/SM ST was actually covering the virtualized environment security mechanisms that we describe at 2.2.1, “Security and virtualization” on page 15.
2.3 The System z operating system security
In this section we briefly describe the main security features of the System z operating system.
2.3.1 z/OS
We dedicate chapter Chapter 3, “z/OS security services” on page 25 to a detailed description of the security features of z/OS.
z/OS did inherit the proven robust infrastructure of the Multiple Virtual Storage (MVS) operating system which, as early as 1973, was the subject of an official IBM Integrity Statement. MVS was the starting point for the line of successors, OS/390® and then z/OS, each release of these operating systems capitalizing on the decades of experience acquired by IBM in the area of IT security.
z/OS V1R7, V1R8, and V1R9, with RACF, have been certified against ISO 15408 at EAL 4+ with the Controlled Access Protection Profile (CAPP) and Labeled Security Protection Profile (LSPP).
z/OS Statement of Integrity As of the writing of this book, the current z/OS level is Version 1 Release 9, and the following System Statement of Integrity has been reissued with this release:
“IBM's commitment includes designs and development practices intended to prevent unauthorized application programs, subsystems, and users from bypassing z/OS security — that is, to prevent them from gaining access to, circumventing, disabling, altering, or obtaining control of key z/OS system processes and resources unless allowed by the installation. Specifically, z/OS “System Integrity” is defined as the inability of any program not authorized by a mechanism under the installation's control to circumvent or disable store or fetch protection, access a resource protected by the z/OS Security Server (RACF), or obtain control in an authorized state; that is, in supervisor state, with a protection key less than 8, or Authorized
18 Designing for Solution-Based Security on z/OS Program Facility (APF) authorized. In the event that an IBM System Integrity problem is reported, IBM will always take action to resolve it.”
Important: It is quite important for the user to understand that authorized programs, by design of the operating system, are entitled to bypass most of the security mechanisms in z/OS and must therefore be highly trustworthy.
It is extremely important that the user can assess such trustworthiness of vendor products that need to be installed in z/OS as authorized programs.
2.3.2 z/VM
z/VM is an hypervisor kind of operating system, that is, it provides virtualized environments for guest Virtual Machines (VM). Figure 2-2 shows z/VM running in a logical partition on System z. Here, z/VM is hosting Linux guest operating systems in virtualized environments. Control Program (CP) is itself the hypervisor piece of z/VM and provides virtual resources to the virtualized environments that map, depending on the nature of the resource, to real system resources.
Logical Logical Logical Partition Partition Partition Logical and physical resources Logical and Logical and z/VM CP physical physical resources resources Linux Linux Linux Guest VM Guest VM Guest VM
Linux Linux Linux z/VM Control Program (CP) virtual virtual virtual Virtualization devices devices devices Virtual devices z/OS Guest LAN IUCV Virtual networks VSWITCH VCTC Linux
HiperSockets PR/SM Microcode virtualization Logical resources PCI FICON OSA HiperSockets networks Crypto Channel Express IFL System z hardware
Figure 2-2 z/VM and PR/SM infrastructures
As already mentioned, CP exploits the SIE (Start Interpretive Execution) function to run the virtualized environments (the guest VMs) in a very tight synergy with System z hardware, that renders the management of these virtual environments especially robust with respect to performance and potential mutual interferences or security exposures.
The virtual storage used by the guest VMs maps to the system real storage through two levels of address translations, which implicitly enhances the strong isolation between virtual environments:
A first-level address translation to provide the guest “real” storage, that is, the set of addresses seen as real storage addresses by the guest operating system. A second-level address translation performed by the guest operating system itself, which then yields virtual storage addresses to the guest.
Chapter 2. System z platform security and certifications 19 z/VM security The VM user is the user who logs on to CP to use a virtualized environment. The VM user is subject to identification and authentication, and the identity is further used to control access to physical and logical resources and the VM environment management commands.
The z/VM access control and privileges policies for the guest VMs are natively (that is, when not using an External Security Manager such as RACF) residing in a “directory” created for each VM guest environment. A directory contains directives set up by the z/VM administrator that address the following items: Virtual Machine identifier (that is, the VM user ID) Virtual Machine password (if no RACF) POSIX user ID (UID) and group ID (GID) Assigned privilege classes Initial and maximum storage sizes Real devices, with exclusive access Simulated devices Virtual devices, such as minidisks Minidisk passwords Permissions to use special CP functions
The IBM recommendation is to use an external security manager such as RACF to complement the access controls specified in the guest VM directories. The z/VM access control infrastructure when using RACF is shown in Figure 2-3.
z/VM CP
Linux user Linux Guest VM Linux Minidisk Linux Data
Linux access control RACF Admin virtual devices RACF service owner ISPF line commands
X CP Access Controls RACF RACF DB Guest virtual Guest VM machine owner (or AUTOLOG) Guest VM Directory SMF Guest VM SMF
Figure 2-3 z/VM and RACF
z/VM and RACF RACF complements the guest directory for: Control of user access to the system (password verification, support for PassTicket) Authorization checking for use of system resources – Minidisks, spool files, RSCS nodes, terminals, directories, and so on
20 Designing for Solution-Based Security on z/OS – Auditing with SMF recording – Any CP command or DIAGNOSE code (including privileged commands and DIAGNOSE codes) – The creation, opening, and deletion of spool files
– The creation and deletion of logical devices – IUCV connections Exit routines for customized checking
The z/VM RACF database can be shared with another z/VM system, or can be shared between z/OS and z/VM. z/VM Statement of Integrity A Statement of Integrity is also issued for z/VM, similar to the z/OS one. It can be found in z/VM General Information, GC24-6095.
Hardware cryptography support z/VM does not, by itself, use the hardware cryptographic coprocessors of System z. It does, however, provide a path to the coprocessors for those guest VMs which are assigned real cryptographic coprocessors in their directory. It is up to the software running in these VMs to provide proper support for integrated hardware cryptography. z/VM allows to assign real cryptographic coprocessors either dedicated to the guest VM, or shared between VMs (this choice depends on the way the VMs are expected to use the coprocessors. Note also that what is dedicated or shared is actually the “domain” in the coprocessor). Refer to z/VM CP Planning and Administration, SC24-6083, for further explanations about the allocation of hardware cryptographic coprocessors to guest VMs, and to Chapter 5, “A brief reminder about System z integrated hardware cryptography” on page 79 for more details on the System z cryptographic device implementation.
Figure 2-4 on page 22 is an example of a VM guest machine setup, where the z/VM system logical partition has access to coprocessors 2, 5, and 6. The z/OS VM guest machine’s directory has been set up to specify dedicated access to domain 1 of coprocessors 5 and 6, and the Linux VM guest machines are sharing access to whatever accelerator is available to the z/VM system.
Chapter 2. System z platform security and certifications 21
Guest Directory CRYPTO APVIRT
z/OS guest Linux guest Linux guest Guest Directory Guest Directory CRYPTO DOMAIN 1 CRYPTO APVIRT APDED 5 6 ICSF libica libica
z90crypt z90crypt
Domain 2 Domain 2
Dedicated Shared queue CP queue LPAR CP
Image profile Usage domain 1,2 + APs 2,5,6 in online/candidate lists Domain Domain 16 domain queues 1 2
Crypto engines Crypto engines
Coprocessor 2 coprocessors 5 and 6
Figure 2-4 Hardware cryptographic coprocessor assignment to VM guest machines
LDAP support at z/VM V5.3 z/VM 5.3 comes with an LDAP client and an LDAP server. They can be used to provide the usual LDAP services to guest VMs or to external systems that have TCP/IP connectivity to z/VM. There is also an LDAP access possible to RACF when the LDAP server is in operation and z/VM has been setup to use RACF.
2.3.3 z/VSE
z/VSE implements security at the platform level to meet the ISO 7498-2 objectives, as shown in the following sections.
z/VSE platform security z/VSE supports the concept of resource managers as components of the operating system that mediate access to resources for applications or subsystems.
Figure 2-5 on page 23 illustrates the implementation: The Basic Security Manager (BSM) that comes with z/VSE is accessible through a Security Authorization Facility (SAF) interface, using the RACROUTE macroinstruction. The Security Server piece is in charge of managing the two Control Files where the user registry and access control information are kept: The VSE Control File contains the user “profiles” The BSM Control File contains the resource “profiles”, the system password rules, the user groups.
Note that the z/VSE IBM BSM can be replaced by a vendor’s External Security Manager (ESM).
22 Designing for Solution-Based Security on z/OS
Resource Managers (CICS, Connector Server, ..) VSE Control Fle BSM Control Fle
RACFROUTE
SAF Router
Security Manager Security Server (ESM)
Figure 2-5 z/VSE Basic Security Manager implementation
z/VSE hardware cryptography support z/VSE provides cryptographic services that transparently invoke the System z hardware cryptographic coprocessors. This is described in detail in 5.5, “Hardware cryptography exploitation on z/VSE” on page 86.
2.3.4 Linux for System z
The Linux implementation for System z takes advantage, whenever possible, of all the System z hardware functions that contribute to system availability and reliability, but Linux itself was not of course initially designed for an optimum synergy with System z hardware, as the IBM operating systems were.
Linux for System z security One of the main objectives in implementing Linux on System z was to provide a Linux version at least as secure as Linux versions for other platforms. As for any version of Linux, Linux for System z benefits from being an Open Source code in that it is scrutinized for proper security by a huge community of users.
The approach in Linux is to provide security functions imbedded in the operating system, but also to take advantage of the many other Open Source or vendor products that can contribute to enhance the platform’s basic security mechanisms. Many add-on security functions are included today in the Linux distributions.
IBM’s contribution to Linux for System z security During the design phase of Linux for System z, IBM ensured that the operating system kernel was meeting the IBM System Integrity objectives. It also ensured that, still by design, Linux for System z can take advantage of, and not be excluded from, the security offerings available on other Linux platforms. Care was also taken to ensure that security solutions can be provided as needed that enable Linux for System z to take advantage of, or complement, the overall System z Security Strategy and Architecture.
Chapter 2. System z platform security and certifications 23 Linux for System z hardware cryptography support When designing the Linux for System z implementation, a specific focus was also given to the exploitation of the System z hardware cryptography infrastructure.
The hardware cryptography infrastructure for Linux for System z is explained in 5.6, “Hardware cryptography exploitation in Linux for System z” on page 87.
Linux for System z certifications IBM has an ongoing commitment to accelerate the development and certification of Linux as a secure, industrial strength operating system. This materializes, as of the writing of this book, in many achievements in getting Linux certified against ISO 15408, the details of which are available at: http://www.ibm.com/security/standards/st_evaluations.shtml
24 Designing for Solution-Based Security on z/OS
3
Chapter 3. z/OS security services
In this chapter we review the security services and APIs delivered in z/OS, as of z/OS V1R9.
3.1 The overall views
Figure 3-1 on page 26 is a graphical overview of the security services and APIs available in z/OS. There are roughly three categories of security services, as follows: Platform Level Security RACF provides a set of services used to achieve Platform Level Security. Transaction Level Security Transaction Level Security is provided via the support of secure protocols such as SSL/TLS or Kerberos, and the ancillary functions that are necessary for the setup of the protocol execution environment. Network Level Security These are the security services available in the z/OS Communications Server.
There are additional APIs and services which are not today embedded in z/OS. These are typically the services and security APIs pertaining to new and specific security models, such as the Java™, J2EE™, or Web Services Security models. These services and APIs are provided by middleware such as the IBM SDK for z/OS and WebSphere Application Server that run on z/OS and establish the application security environment in their runtime.
There is also z/OS support for the OpenSSH protocol support, which is provided as a non-priced program product to be installed in z/OS (IBM Ported Tools for z/OS, Program Number 5655-M23).
There are three services that the z/OS platform provides for users who happen to be z/OS or non-z/OS users: z/OS PKI Services z/OS PKI (Public Key Infrastructure) Services is the z/OS implementation of a PKIX Certificate Authority.
© Copyright IBM Corp. 2008. All rights reserved. 25 The z/OS LDAP Directory server z/OS does not require an LDAP server for its own internal operations. The z/OS LDAP server can be exploited by users on other systems to remotely access z/OS services via the LDAP protocol (these services are developed in “Remote Services” on page 30), or can be used as in any other LDAP implementation as network-accessible data repository. The z/OS Kerberos Key Distribution Center z/OS can act as a Kerberos KDC, that is, it can provide Kerberos tickets to clients. These tickets can be used for authentication to Kerberos-enabled applications that run on z/OS or other platforms. Optionally, session keys in the tickets can also be used by the applications to perform data integrity or encryption.
network
Network level Security
FTP, TN3270, Middleware z/OS IP Filtering HTTP Server Security LDAP IPSec VPNs WAS for z/OS z/OS Directory Intrusion CICS/TS JAVA PKI J2EE Server Detection Services WebSphere MQ Services WSS and AT-TLS ... ELF/DCAS client OpenSSH….
A P I s System SSL Network Authentication Enterprise Identity z/OS Security Server (RACF) Service (Kerberos) Mapping (EIM) DCE Security Server ICSF Transaction OCSF/OCEP RACF Level Platform Security level Security z/OS
Figure 3-1 z/OS security services and APIs
Another view of the z/OS security services and APIs can consist of looking at the protocols and data formats, that is, the standards, used to exchange security-related information and to establish secure communications with other systems. These standards are summarized in Figure 3-2 on page 27. Note that all these standards are widely adopted by the industry, thus making a seamless insertion of z/OS in a network of distributed systems a quite realistic expectation.
26 Designing for Solution-Based Security on z/OS
LDAP OpenSSH CRAM-MD5 Kerberos J2EE DiGEST-MD5 SSL TLS XML SPKM-3 SOAP LIPKEY WSS Network SAML level X.509 TCP/IP services Security JAVA PKCS#10 IP V4/V6 FTP, TN3270, … z/OS PKCS# 7 IPSec HTTP Server Middleware IP Filtering LDAP PKCS#12 IKE WAS for z/OS Security z/OS IPSec VPNs Directory OCSP CICS/TS JAVA PKI Intrusion Server WebSphere MQ J2EE RSA DSA Detection Services Services ... WSS and SCEP AT-TLS client ELF/DCAS OpenSSH….
System SSL z/OS Security Server (RACF) Network Authentication Enterprise Identity Mapping X.509 Service (Kerberos) (EIM) DCE Security Server PKCS#10 ICSF PKCS# 7 RACF DES T-DES OCSF/OCEP Transaction Platform PKCS#12 Level level RSA DSA AES SHA Security RSA EMV Security XML PKCS11
Figure 3-2 Security-related standards supported by z/OS
3.2 z/OS security services and APIs
The z/OS security services that come as z/OS components are actually packaged as the following sets of z/OS services: Cryptographic Services Security Server Integrated Security Services IBM Tivoli Directory Server for z/OS Communications Server
We give here a brief description of these security services; further details about some of the services will be developed in other sections. We do not give details on the services provided by middleware such as WebSphere Application Server. This will be addressed later in the book in 9.1, “Security environments and WebSphere Application Server for z/OS” on page 156.
3.2.1 z/OS Cryptographic Services
Integrated Cryptographic Service Facility The Integrated Cryptographic Service Facility (ICSF) is the z/OS component that both drives the System z hardware cryptographic coprocessors and provides the IBM Common Cryptography Architecture (CCA) for the applications or middleware to invoke the hardware cryptographic services. The CCA API is available to Assembler and high-level language applications.
The System z cryptographic services are described in Chapter 5, “A brief reminder about System z integrated hardware cryptography” on page 79.
The following IBM Redbooks publications specifically address the hardware coprocessors and ICSF support as provided on the various System z models: zSeries Crypto Guide Update, SG24-687
Chapter 3. z/OS security services 27 IBM eServer zSeries 990 (z990) Cryptography Implementation, SG24-7070 z9-109 Crypto and TKE V5 Update, SG24-7123
Note: As of the writing of this book, the ICSF FMID HCR7740 is delivered in the z/OS V1R9 Cryptographic Services, and the more recent FMID HCR7750 ICSF release, which provides additional functions to HCR7740, can be downloaded from: http://www-1.ibm.com/servers/eserver/zseries/zos/downloads
Open Cryptographic Service Facility OCSF The Open Cryptographic Service Facility is the OS/390 implementation of the Intel® Common Data Security Architecture (CDSA) API. OCSF is provided for C/C++ applications. It is described in OS/390 Security Server 1999 Updates Technical Presentation Guide, SG24-5627, and OS/390 Security Server 1999 Updates Installation and Implementation Guide, SG24-5629.
OCSF can also exploit “Trust Policy” plug-ins delivered in z/OS. Roughly, a Trust Policy plug-in is a software component that is used to verify the validity of digital certificates or chains of certificates. z/OS comes with OCEP and pkitp as application-usable Trust Policy plug-ins: Open Cryptographic Enhanced Plug-in (OCEP) complements OCSF to exploit certificates stored in the RACF database. pkitp provides OCSF with additional capabilities regarding the validation of certificates and certificate chains using Certificate Revocation Lists (CRLs) residing in an LDAP directory. Beginning with z/OS V1R7, pkitp can also access CRLs via the HTTP protocol or get a certificate revocation status provided via the Online Certificate Status Protocol (OCSP).
System SSL System SSL is a base component of z/OS. It is a set of libraries that C/C++ applications can use to protect TCP/IP socket communications using the Secure Socket Layer (SSL), or the newer Transport Layer Security (TLS) protocol by calling the System SSL API. System SSL is steadily updated to extend the TLS protocol capabilities as proposed in existing or new RFCs, and to take advantage of new hardware cryptographic coprocessor technologies.
z/OS PKI Services z/OS Public Key Infrastructure Services is an industry-class Registration and Certification Authority software that runs on z/OS. It exploits the capability of RACF, or an equivalent product, to protect the Certificate Authority signature private key and also exploits, whenever possible, the z/OS hardware cryptography services. z/OS PKI Services is specifically addressed in Implementing PKI Services on z/OS, SG24-6968.
z/OS Security Server z/OS Security Server contains the Resource Access Control Facility (RACF) product. Note that although RACF is always delivered with z/OS, it needs proper licensing to be authorized for use.
We dedicate a chapter to RACF in Chapter 4, “Focusing on the z/OS Security Server (RACF)” on page 41.
28 Designing for Solution-Based Security on z/OS 3.2.2 z/OS Integrated Security Services
LDAP Directory Server The LDAP Directory Server supports several “backends”. Its relationship with security is twofold: It can host any security data that an enterprise might want to make available via TCP/IP and the LDAP directory. In that case the directory data is stored in DB2 tables or z/OS UNIX® files. It can be used to access USER and GROUP profile contents in the RACF database. It uses the so-called “SDBM backend” to translate LDAP commands into RACF commands, and RACF profiles into LDAP directory tree “entries.”
The z/OS LDAP Server can also publish changes to the RACF database or other directories hosted on z/OS as entries appearing in an “LDAP Change Log” directory.
Further information about the z/OS LDAP Server can be found in: OS/390 Security Server 1999 Updates Technical Presentation Guide, SG24-5627, and OS/390 Security Server 1999 Updates Installation and Implementation Guide, SG24-5629 Putting the Latest z/OS Security Features to Work, SG24-6540 z/OS 1.6 Security Services Update, SG24-6448
Important: As of z/OS V1R6 the z/OS Integrated Security Services LDAP Server is stabilized; no new LDAP functions will be implemented in this LDAP Server. At the time of writing, z/OS V1R10 is previewed as the last release that delivers the z/OS Integrated Security Services LDAP. As of z/OS V1R8, another LDAP Server is provided in z/OS, in addition to the Integrated Security Services LDAP Server: the IBM Tivoli Directory Server for z/OS (ITDS). This LDAP Server becomes the z/OS strategic LDAP Server. The z/OS LDAP client is updated in z/OS V1R8 to become the ITDS for the z/OS LDAP client.
This evolution of the z/OS LDAP Server is described in 3.2.3, “IBM Tivoli Directory Server for z/OS” on page 31.
Network Authentication Service Network Authentication Service was initially the z/OS implementation of the Kerberos authentication protocol and Key Distribution Center, along with the support of the Generalized Security Services API (GSS-API), or the Kerberos API, for C/C++ Kerberos-enabled applications. Access to a subset of the GSS-API functions has been made available to non-Language Environment applications with the R_GenSec RACF callable services. Kerberos is a widely used authentication protocol in the distributed world, today at Version 5 and supported by many platforms such as UNIX, AIX®, Windows®, and so forth. z/OS applications that are Kerberos-enabled can interoperate for authentication, and optionally for encryption of data, with partner applications on those platforms. As of the writing of this book the following z/OS applications are Kerberos-enabled: DB2 V7 and above (for authentication) FTP client and server (for authentication, optionally data integrity and privacy) Telnet server (for authentication, optionally for data integrity and privacy) LDAP client and server (for authentication)
Chapter 3. z/OS security services 29 rshd server (for authentication, optionally for data integrity and privacy) NFS server (for authentication, data integrity and privacy)
More information on the z/OS Kerberos implementation is available in “The z/OS Network Authentication Service” on page 111 and in Putting the Latest z/OS Security Features to Work, SG24-6540 and z/OS 1.6 Security Services Update, SG24-6448.
Note: The Kerberos design is well fit for authentication in an intranet. However, constraints regarding network availability and scalability in the number of participants makes it less suitable for Internet communications. There, the X.509 digital certificate technology should be used instead of Kerberos tickets.
At z/OS V1R9, the Network Authentication Service component also supports the SPKM-3 protocol (Simple Public Key Mechanism Support-3 - See RFC 2025 for the specification of SPKM-3) and the LIPKEY protocol (Low Infrastructure Public Key Mechanism - See RFC 2847 for the specification of LIPKEY). This support is integrated in the GSS-API z/OS implementation where SPKM-3 and LIPKEY can be declared as GSS-API mechanisms.
z/OS as a Kerberos Key Distribution Center z/OS can act as a Kerberos KDC, that is, it can provide Kerberos tickets to clients. These tickets can be used for authentication to Kerberos-enabled applications that run on z/OS or other platforms. Optionally, session keys in the tickets can also be used by the applications to perform data integrity or encryption.
A Kerberos KDC operates with a Kerberos user registry. On z/OS this registry can be residing in z/OS UNIX files, or in the RACF data base. The use of RACF as a Kerberos user registry is further discussed in 4.2.6, “RACF as a Kerberos user registry” on page 49.
Enterprise Identity Mapping (EIM) Enterprise Identity Mapping is a facility delivered in z/OS that installations can use as an identity mapping mechanism. It comes in two pieces: A set of administrative utilities and APIs to build and maintain identity mapping information in an LDAP directory, which is then called the EIM “Domain Controller”. An EIM client API for C/C++ and Java applications that allows these applications to connect to the EIM Domain Controller and get the mapping information via the LDAP protocol.
The intent is that these applications can then map the foreign user identity they have been provided with to an identity local to the platform they are executing on. This local identity can then be used by the access control mechanism of this platform.
EIM is further described, with examples, in z/OS 1.6 Security Services Update, SG24-6448.
Remote Services A set of three z/OS services, at z/OS V1R8 and above, are made available to remote applications via the LDAP protocol. They are:
The z/OS Identity Cache The z/OS Identity Cache enables an application to maintain identity information across security domains, so that individual accountability is not lost. Distributed applications can use the z/OS Identity Cache to enable end-to-end auditing that tracks the identity initially used for authentication as well as the identity on the current platform. Remote authorization
30 Designing for Solution-Based Security on z/OS Remote authorization allows resource managers that do not reside on z/OS to centralize authorization decisions using the z/OS Security Server RACF via the LDAP protocol. Remote auditing Remote auditing allows resource managers that do not reside on z/OS to centralize security event logging using z/OS Security Server RACF via the LDAP protocol.
These remote services and their setup are further described in 4.5.4, “RACF remote services at z/OS V1R8” on page 64.
Important: The remote services are not supported by the z/OS Integrated Security Services LDAP server. They require the new IBM TDS server in the z/OS system. See 3.2.3, “IBM Tivoli Directory Server for z/OS” on page 31 for information about the new z/OS LDAP server.
3.2.3 IBM Tivoli Directory Server for z/OS
Figure 3-3 on page 32 shows the evolution of the z/OS LDAP server and client over time and depicts the situation at z/OS V1R9, where two LDAP servers and one LDAP client are delivered in z/OS.
The z/OS Integrated Security Services LDAP server This is the LDAP server available since OS/390 V2R5, which has been functionally upgraded until z/OS V1R6. At this stage this LDAP server is stabilized and will not receive any new functional upgrade. It will, however, receive updates that affect the server internal schemas.
Users of this LDAP server are advised to consider migrating to the IBM TDS server for z/OS because the ISS LDAP will eventually be discontinued after z/OS V1R10, as per the z/OS V1R10 preview published during the writing of this book.
The IBM Tivoli Directory Server for z/OS This LDAP server is also delivered in z/OS starting with z/OS V1R8, with APAR OA15948, and is intended to implement any new LDAP-based functions that IBM plans to make available in z/OS.
The z/OS LDAP client The z/OS LDAP client has been replaced by the IBM TDS client for z/OS at z/OS V1R8.
Chapter 3. z/OS security services 31
Last functional upgrade APAR OA15948 z/OS V1R8 z/OS z/OS TDBM coex OS/390 V1R4 V1R6 V2R5
ISS LDAP Server Stabilized ISS LDAP Server
FMID HRSL380 Directory Server For z/OS
March Enablement 2007 APAR OA19286 For z/OS V1.8 only Additional APIs OS/390 z/OS V2R4 V1R8
ISS LDAP Client Directory Client For z/OS
Figure 3-3 The z/OS LDAP server and client evolution
The z/OS LDAP infrastructure Figure 3-4 is a global overview of the z/OS LDAP infrastructure as implemented with the ISS LDAP server and the IBM TDS.
IODF backends IODF Schema Basic auth SSL/TLS Kerberos z/OS HCD CRAM-MD5 Digest-MD5 RMF RMF schema RMF
TCP/IP SDBM LDAP client stack LDAP V3 RACF Data RACF z/OS LDBM base Schema UNIX
config GDBM LDAP client HFS ISS LDAP zFS ACL Schema Only TDBM Directory Applications
ldapsearch EXOP ITDS only ldapmodify OMVS shell DB2 ldapdelete TSO ldapmodrdn Directory ACL Schema
Figure 3-4 The z/OS LDAP infrastructure
The z/OS LDAP server is intended to support interactions with LDAP clients that go beyond the classical use of an LDAP directory. It comes with “backends” that support these specific interactions along with the connections to specific data repositories. The backends available as of z/OS V1R9 are listed below. Note that the LDAP server can run with a mix of active backends. The HCD backend This backend allows an authorized user to perform I/O Definition Files administration from a remote LDAP client.
32 Designing for Solution-Based Security on z/OS
Important: This backend is operating only with the ISS LDAP server. There is no plan as of today to make the same backend available for the IBM TDS as well.
The RMF™ backend RMF data can be collected from an authorized LDAP client. The RMF LDAP backend routes the incoming requests to the RMF Distributed Data Server (DDS) and returns the requested data to the LDAP client.
Important: This backend is operating only with the ISS LDAP server. There is no plan as of today to make the same backend available for the IBM TDS as well.
The SDBM backend The SDBM backend allows authorized LDAP clients to access, in search or update, RACF data kept in the USER and GROUP profiles. The LDBM backend This backend provides the “classical” LDAP service, that is, the capability of storing and retrieving information in an LDAP directory. The directory data is backed up in z/OS UNIX files. If the LDAP object stores user passwords, the LDBM backend can proceed with an encryption of the passwords; or if the user happens to also be a RACF user, it can refer to the password as stored in the user’s RACF USER profile (z/OS LDAP “Native Authentication”).
Important: This backend is only available with the IBM TDS - The ISS LDAP server can only use DB2 to back up the LDAP users’ data (that is, it only supports the TDBM backend).
The GDBM backend The GDBM backend directory is a journal of changes that occurred in other directories managed by the LDAP server in the z/OS image. The intent is to make the occurrence of a change directly visible to an LDAP client, assuming that this LDAP client will then manage to inspect and get the relevant changed data.
Important: The GDBM backend when running with the ISS LDAP can only back up its directory data in DB2 tables. If running with the IBM TDS, the data can be backed up in z/OS UNIX files or DB2 tables.
The TDBM backend This backend provides the “classical” LDAP service, that is, the capability of storing and retrieving information in an LDAP directory. The directory data is backed up in DB2 tables. If the LDAP object stores user passwords, the TDBM backend can proceed with an encryption of the passwords; or if the user happens to also be a RACF user, it can refer to the password as stored in the user’s RACF USER profile (z/OS LDAP “Native Authentication”). When running with the IBM TDS server, the user has the choice to store the directory data in z/OS UNIX files (with the LDBM backend) or in DB2 tables (with the TDBM backend). Both backends support the same functionalities. The choice is mainly driven by data volume size and scalability considerations.
Chapter 3. z/OS security services 33 The EXOP (Extended Operations) backend Actually, this EXOP backend in the figure is some kind of “place holder” for specific services provided by z/OS LDAP, like the remote services mentioned in “Remote Services” on page 30. All the backends we described are exploited using standard LDAP commands (ldapsearch, ldapmodify, and so on). The Extended Operation is a provision in the LDAP protocol to convey non-standard LDAP commands.
z/OS LDAP and Sysplex The z/OS ISS LDAP server and the IBM TDS for z/OS can operate in a Sysplex configuration and share the data repository used by the SDBM, TDBM, or LDBM backends between instances of the server in the Sysplex, that is, exploit the sysplex data sharing capability of RACF, DB2, and HFS. This configuration enhances the availability of the LDAP services as provided by the members of the Sysplex and also allows balancing of the LDAP workload, as it can be achieved using a z/OS Sysplex Distributor configuration. A high-level view of the LDAP configuration in a z/OS sysplex is shown in Figure 3-5.
Sysplex member
LDBM TCPIP LDAP stack V3 TDBM Sysplex Distributor z/OS UNIX RACF HFS Directory Schema LDAP zFS ACL client WLM RACF DB2 Sysplex member Directory ACL Schema LDBM TCPIP LDAP stack V3 TDBM
z/OS UNIX RACF Sysplex data sharing
Figure 3-5 z/OS LDAP and Sysplex
Note that, besides Sysplex data sharing, this configuration, when running with the IBM TDS for z/OS, also exploits XCF signalling between the instances of the LDAP server for the purpose of synchronization of operations and data.
z/OS LDAP and LDAP replication The LDAP replication function is supported by the z/OS LDAP server with the TDBM or the LDBM backend, in the master-replica mode or peer-to-peer replication mode. Note that, when using the IBM TDS for z/OS, the set of LDAP servers operating in Sysplex mode in a specific sysplex can be considered as a single node for LDAP replication. Figure 3-6 on page 35 illustrates the setup for LDAP replication with z/OS LDAP.
34 Designing for Solution-Based Security on z/OS
LDBM z/OS HFS zFS Directory ACL Schema TCP/IP LDAP V3 LDAP client stack z/OS UNIX
DB2 Directory ACL Schema
TDBM
Optional SSL/TLS
z/OS LDBM
HFS zFS Directory ACL Schema TCP/IP LDAP V3 LDAP client stack z/OS UNIX DB2 Directory ACL Schema
TDBM
Figure 3-6 z/OS LDAP replication
Important: As implicitly stated above, there is no LDAP replication support on z/OS when using the SDBM backend, that is, one cannot synchronize RACF data bases using the z/OS LDAP replication.
The z/OS LDAP services are further discussed in 4.5, “Accessing RACF using the LDAP protocol” on page 59 and in Chapter 6, “Using the LDAP directory as a User Registry” on page 91.
3.2.4 z/OS Security Level 3 optional feature
There is a need, for some of the z/OS components, to abide by the exportation restrictions regarding cryptographic functions. Although the regulation is rather complicated, and evolving, regarding the exact definition of those restrictions a rough approach is to say that the z/OS components are allowed to use symmetric algorithms (that is, DES, RC2, and RC4) with keys less than 64 bits long. There is no length limitation regarding the asymmetric algorithm (RSA and DSA) keys as long as these algorithms are used to encrypt symmetric keys or for digital signature purposes.
The capability of using symmetric keys greater than 64 bits is provided by installing the unpriced feature of z/OS, z/OS Security Level 3. The feature must be explicitly ordered (that is where the export control comes to play) and it extends the allowed key length for the following z/OS components: LDAP Server and Client (ISS LDAP and IBM TDS) OCSF Network Authentication Service
Chapter 3. z/OS security services 35 System SSL, and therefore all z/OS servers and client applications that use SSL/TLS for TCP/IP sockets data protection.
With the Security level 3 feature installed, these components can use these algorithms: Triple-DES, with a key of 168 bits long RC4, with a key of 128 bits long AES, with a key of 128, 192 or 256 bits long
Further details about the /OS Security Level 3 optional feature can be found in z/OS and z/OS.e Planning for Installations, GA22-7504.
3.2.5 Security functions in the z/OS Communications Server We focus here on the TCP/IP security-related functions provided in the z/OS Communications Server. These functions pertain either directly to TCP/IP services provided by the Communications Server, such as FTP, Telnet, and so on, or to more generic functions such as IP filtering, Virtual private Networks, and so on.
The TCP/IP services security protections consist of: FTP protection via SSL/TLS or Kerberos authentication (and optionally data integrity and privacy) TN3270 via SSL/TLS Telnet via Kerberos authentication rshd via Kerberos authentication sendmail via SSL/TLS The Open Shortest Path First (OSPF) dynamic routing protocol supports message authentication and message integrity of OSPF routing messages through the use of the OSPF MD5 Authentication security protocol as defined by RFC 2328. This is implemented via the OMPROUTE service of the Communications Server. The Communications Server supports DNS at Version 9 of BIND. This level of DNS has built-in security features, with extensions to DNS that provide data integrity and authentication to security-aware resolvers and applications through the use of cryptographic digital signatures. Also, transaction level authentication, using shared secrets and one-way hashing, authenticates dynamic updates as coming from an approved client, or responses as coming from an approved recursive name server. The SNMPv3 security level. The SNMPv3 framework defines several security functions, such as USM for authentication and privacy, and the view-based access control model (VACM), which provides the ability to limit access to different MIB objects on a per-user basis, and the use of authentication and data encryption for privacy.
More generic functions of the z/OS Communications Server: Integrated IP security, which provides static IP filtering and IPSec VPNs. Application Transparent TLS (AT-TLS), where the Communications Server does provide SSL/TLS protection for applications not enabled for SSL or TLS support. Intrusion Detection Services (IDS). We further discuss the z/OS Communications Server Security services in Chapter 8, “Overview of TCP/IP network security” on page 123.
Relevant details about the security features of the z/OS Communications Server and their setup can be found in z/OS Communications Server IP Configuration Guide, SC31-8775.
36 Designing for Solution-Based Security on z/OS 3.2.6 Communications Server Security Level 3 optional feature The z/OS Security Level 3 optional feature extends, in compliance with the exportation restrictions, the length of symmetric cryptography keys that components of the Communications Server use. The following component is affected by the installation of Security Level 3: IP Security, with the IPSec VPNs being able to use the Triple-DES encryption algorithm.
3.2.7 Additional product - OpenSSH for z/OS OpenSSH for z/OS comes as the z/OS IBM Ported Tools product, Program Number 5655-M23. OpenSSH is a suite of popular UNIX connectivity tools providing secure remote login, remote shell, and ftp between SSH clients and the server. z/OS IBM Ported Tools is an unpriced product that nevertheless needs to be ordered, and comes as an SMP/E installable program.
OpenSSH for z/OS is further discussed in z/OS 1.6 Security Services Update, SG24-6448.
3.3 A word on authorized programs and the z/OS APF facility
Many system functions, such as entire supervisor calls (SVC) or special paths through SVCs, are sensitive; that is, access to these functions must be restricted to trusted authorized programs to avoid compromising the security and integrity of the system.
In consequence, before a program can access a restricted SVC in MVS, it must be in an authorized status to do so. z/OS considers a program to be authorized if it executes under one or more of the following conditions: With, or with the capability to obtain, a system protection key (that is, a PSW storage key with a value between 0 and 7 included) In supervisor state With Authorized Program Facility (APF) authorization
In addition to APF-authorized programs, which are usually entire job steps (see more information on APF authorization in “The Authorized Program Facility (APF)” on page 37), z/OS authorized programs include SVCs, PCs, PTs, and certain exit and I/O appendage routines that are called by authorized programs.
The PSW storage key a program starts to run with is determined by the contents of the so-called “PPT table” (Program Property Table) in SYS1.PARMLIB(SCHEDxx).
A program starts its execution in supervisor state as per design of the operating system, or can switch to supervisor state because it is authorized to a system service that allows switching into supervisor mode, or it is switched into supervisor state by another authorized program.
The Authorized Program Facility (APF) APF allows an installation to identify system or user programs that can use sensitive system functions, that is, functions that can be called only by authorized programs. APF does the following: Restricts the use of sensitive system SVC routines and sensitive user SVC routines (optional) to authorized programs.
Chapter 3. z/OS security services 37 Allows the system to fetch all modules in an authorized job step task only from authorized libraries to prevent programs from counterfeiting a module in the module flow of an authorized job step task. An APF-authorized program can access system functions, such as entire supervisor calls (SVCs) or special paths through SVCs, that can affect the security and integrity of the system. APF-authorized programs are usually entire job steps.
A program becomes APF-authorized when it meets these two conditions: It resides in an APF-designated library. These libraries are specified in SYS1.PARMLIB(PROGxx). The list can be dynamically modified by the SETPROG and SET PROG operator commands. It has been link-edited with AC=1 (Authorization Code=1) as a load module that resides in the APF-designated library.
It is therefore highly recommended that proper RACF protection be used to control access to the APF libraries as well as to the operator commands that modify the list of APF libraries.
Note that if a user tries to run a program from an authorized library that is not linked AC=1, it will not run APF-authorized, but that same program could be fetched by another that is running APF-authorized and executed in the authorization state in which it is called, or even have its state changed.
Attention: The system automatically adds SYS1.LINKLIB and SYS1.SVCLIB to the APF list at IPL. In addition, any module in the link pack area (pageable LPA, modified LPA, fixed LPA, or dynamic LPA) will be treated by the system as though it came from an APF-authorized library. Users must ensure that they have properly protected SYS1.LPALIB and any other library that contributes modules to the link pack area to avoid system security and integrity exposures, just as they would protect any APF-authorized library.
APF and z/OS UNIX System Services The APF rules for programs that reside in the z/OS UNIX file system are similar to those for programs that reside in authorized libraries. Setting the APF-authorized extended attribute bit, also known as the “a” bit, should be thought of as putting that program into an authorized library.
3.4 A word about auditing
This section is intended to remind you what the two sources of security-related auditing data are in z/OS.
3.4.1 RACF auditing data
Details on RACF-generated auditing data are provided in 4.3, “RACF auditing” on page 51.
Note that besides RACF-based auditing, applications can request to generate SMF auditing records using the R_auditx RACF callable service, as explained in “SMF records that report security-relevant events detected by RACF or applications” on page 52.
38 Designing for Solution-Based Security on z/OS 3.4.2 Syslog daemon (syslogd)
Syslogd is a z/OS UNIX utility used to collect messages issued by UNIX applications and to log them as per directives set up in its configuration file. Applications that are designed to use syslogd for logging invoke a local instance of syslogd, or connect, via TCP/IP UDP, to a syslogd instance running in a remote system.
Details about z/OS syslogd setup and operations can be found in z/OS Communications Server IP Configuration Guide, SC31-8775.
Be aware that receiving remote messages on a local syslogd instance is a potential security exposure because it entails opening a TCP/IP port (port 514) for incoming communications. It is therefore strongly recommended that connections from remote applications be protected, such as establishing IPSec VPNs between the remotely requesting application’s TCP/IP host and the local syslogd instance host.
The syslogd configuration file is used to define logging rules and output destinations for error messages, authorization violation messages, and trace data. Logging rules are defined using a facility name and a priority code. For locally generated messages, the user ID and job name of the program that generated the message can also be specified in the rule. For messages arriving over the network, the rule can include the IP address or host name of the sender. The facility name and priority code are passed on the logging request from an application when it wants to log a message. The user ID and job name are provided by the system.
The facility name that an application uses in the messages sent to syslogd is a matter of conventions established when developing applications that use the daemon.
The priority codes are standardized as follows (in decreasing priority order): emerg/panic A panic condition was reported to all processes alert A condition that should be corrected immediately crit A critical condition err(or) An error message warn(ing) A warning message notice A condition requiring special handling info A general information message debug A message useful for debugging programs none Do not log any messages for the facility * A place holder used to represent all priorities
z/OS syslogd supports the following logging destinations for the messages it receives: /file A specific path (for example, /tmp/syslogd/auth.log) @host A syslog daemon on another host (for example, @mya1xserver) user1,user2,... A list of users /dev/console The MVS console /dev/operlog The MVS operlog log stream $SMF The log message is stored in SMF record type 109
Chapter 3. z/OS security services 39
40 Designing for Solution-Based Security on z/OS
4
Chapter 4. Focusing on the z/OS Security Server (RACF)
As we have seen, the IT user community is now engaged in an evolution of operational models where companies need to connect to customers, suppliers, service providers, and distributors using a variety of distributed applications running on different computer platforms, via a variety of networking techniques. A transaction may start from anywhere on the Internet and can proceed through multiple computer platforms distributed across the world. Internet banking is an example of such a chain of operations.
This leaves us with the challenge of providing end-to-end security across multiple platforms and networks, with strong requirements for any involved platform to provide the following: Platform integrity, ensuring protection of data and other resources residing on the platform. Proper and consistent identification and authentication of users who can enter the system through multiple ports of entry. Proper and consistent auditing and logging, preserving, whenever possible, individual users’ accountability.
4.1 What is RACF
The Multiple Virtual Storage (MVS) operating system was designed in the 1970s to run on System/370™ (S/370™), for the secure execution of multiple applications on one system by multiple users. RACF was introduced in 1976 to work on top of the strong hardware and operating system layers to provide applications with a common point of user authentication and access control services. It was then termed an “External Security Manager, because security management was then becoming “external” to the applications.
Since then RACF has grown and has been adapted to meet the specific needs and challenges of new security technologies supported by the OS/390 and z/OS operating systems, and is today a major contributor towards e-business applications’ end-to-end security.
© Copyright IBM Corp. 2008. All rights reserved. 41 As of z/OS V1R9, RACF provides support for the following security services: User identification and authentication for z/OS users via password, PassTicket, or password phrases. User identity mapping for z/OS users authenticated via a X.509 digital certificate or Kerberos ticket. Resource access control for z/OS applications and components, on the basis of users’ identity or group of users membership. X.509 digital certificate management Kerberos user registry Remote security services via the z/OS LDAP server Support of the J2EE role security model Auditing of all security events detected by RACF or reported to RACF
4.1.1 The RACF infrastructure for identification, authentication, and authorization
The RACF infrastructure is illustrated in Figure 4-1 on page 43. RACF maintains a user registry and authorization database that contains the following: Information pertaining to registered users, such as identity and passwords and other security-related attributes. Note that “user” here is a generic term that designates either a real end user of the system or an application that is running in the system under a “technical” identity. RACF also supports the concept of group of users to designate a set of users, with installation-related specific characteristics that make it possible to treat them as a single entity. Information about users and groups of users is kept in database records called “profiles”. The label, or name, of a USER profile is the RACF identity of the user (userID), while the label of a GROUP profile is the group name. A definition of the resources to be protected, in resource profiles. Each resource profile contains a list (the access list) of users permitted to access the resource and, if needed, the access given by default to the resource. RACF also supports an optional Multilevel Security (MLS) security model. When MLS is active the access to a resource also depends on the “security label” assigned to the resource, in its profile, as well as its requestor’s own security label. A RACF-protected resource is designated by its nature (the “class”) and its profile name.
The profiles in the RACF database are defined and maintained by RACF administrators or users declared as “owner” of the resources.
Note: RACF also supports controlling access for certain kinds of resources that are not registered with profiles in the RACF database. z/OS UNIX resources are examples of such types of resources.
However, RACF still creates the data structures where access control information is kept, as is the case for the z/OS UNIX file File Security Packet (FSP), that RACF creates in the file system. But it is up to the resource manager (we explain what a resource manager is) to provide RACF with information that enables it to make an access control decision and to generate the relevant auditing data.
42 Designing for Solution-Based Security on z/OS
Application z/OS RACF Address Space Database
1 User Identification User Profiles And Administrator Authentication Resource Access User or identity 2 Lists mapping S request To access A Resource userID F group… z/OS 3 Resource 4 Code Manager RACF requests to access a resource
X System Management 6 5 Facility
Resource
Auditing
Auditor
Figure 4-1 The RACF infrastructure
The following interactions occur in the infrastructure shown in Figure 4-1: 1. An application, or a z/OS component, requests the user for identification and authentication data. z/OS provides support for several forms of identification and authentication that include, for example, a user identity and a password, or a digital certificate, or a Kerberos ticket. 2. Assuming that the user provides a userID and a password to the requesting application, the application calls RACF to evaluate the validity of both entities: userID and password. If the user authenticates with a digital certificate or a Kerberos ticket, then it is up to the application to proceed with validation of the certificate or the ticket. Once this validation is done the application calls RACF to provide a RACF userID that maps to the certificate or the Kerberos ticket. RACF responds to the request by return and reason codes, and a RACF userID, in the case of a successful mapping request, that indicate whether the operation was successful in RACF. 3. The application now runs under a RACF userID, which is used to access a resource in the system, and the list of user groups this specific userID belongs to. 4. In z/OS access to the resources is mediated by specialized z/OS components called “resource managers”. It is the role of the resource manager to call RACF to verify that the user can be granted access to the resource. 5. Likewise, it is also the role of the resource manager to deny or grant access to the resource to the application according to the response from RACF.
Chapter 4. Focusing on the z/OS Security Server (RACF) 43 6. Authentication, access to resources and other security events can be recorded in an audit trail made of z/OS SMF records.
Note that specific RACF users can be given the AUDITOR attribute and can define auditing criteria. RACF can enforce a separation of duties with respect to security administration and auditing by allowing the administrator to change access control rules and user definitions but not to change certain auditing controls. Conversely, the auditor can change auditing controls but cannot make administrative changes to RACF profiles. In other words, the administrator cannot prevent the auditor from auditing the administrator, while the auditor cannot authorize himself or herself to resources.
The System Authorization Facility (SAF) interface SAF is the interface provided in z/OS for applications to ask for External Security Manager services. SAF can be invoked in two ways: By using the RACROUTE macro instruction in the application that needs security services. By using the RACF Callable Services. These callable services are usable by applications running in a variety of execution environments, such as Language Environment® or Java, that can thus also benefit from the External Security Manager centralized security implementation.
SAF also makes possible customization of service request processing by allowing the installation of a customer exit module that takes control before the request is forwarded to the External Security Manager.
Finally, SAF allows to use an External Security Manager other than RACF with minimum changes to the applications. CA’s ACF2 or Top Secret are such alternate products.
4.1.2 Sharing or synchronization of the RACF data base
Installations may find it beneficial to share the same RACF data base between different instances of RACF in different z/OS images. This can easily be achieved in a Parallel Sysplex® configuration by using the RACF data sharing mode function. It can also be achieved in any configuration by synchronizing the access to a single database by many RACF instances. In that case GRS provides the required synchronization.
Another approach may be to synchronize the contents of different RACF databases, thus having several different systems sharing the same single “logical view” of the RACF database contents. RACF provides the RACF Remote Sharing Facility (RRSF) for this purpose. RRSF can be configured, if desired, by the security administrators, so that end users’ RACF passwords, as well as other security information, will be copied to other RACF systems automatically and securely according to a preset installation policy.
Alternatively, RACF USER and GROUP profiles can be synchronized in different RACF data bases using an LDAP infrastructure, where each data base is hosted by a z/OS instance which has the LDAP server with the SDBM backend operating. A properly programmed LDAP client is then managing to transfer data between the different z/OS instances. The IBM Tivoli Directory Integrator (ITDI) is such an LDAP client.
4.2 RACF security functions
We now introduce the security functions of RACF.
44 Designing for Solution-Based Security on z/OS 4.2.1 Identification and authentication
RACF keeps a record of all registered users in the RACF data base. When a user logs on to an application specifying an identity and a password, the application calls RACF to verify this identity and password. RACF searches its data base for a USER profile with a matching name, the conditions for this verification to succeed being that RACF finds the profile for the submitted userID and the received password matches the password kept in the profile.
For security reasons the password is not kept in clear text in the RACF USER profile. It is stored encrypted with a one-way encryption algorithm. The same algorithm is used to encrypt the password passed for verification in order to check for a match.
When conditions are met for a successful authentication, RACF then collects further information about the user from other stored elements in the RACF data base and creates a z/OS data construct called an Access Control Environment Element (ACEE). The ACEE is a credential that remains associated with the process initiated by the authenticated user, and is further used to identify the execution thread that requests access to RACF-protected resources for access control authorization checking and for auditing.
Characteristics of the RACF password The RACF password is eight (maximum) characters long. Valid characters for passwords are alphabetic uppercase A–Z, numeric (0–9), and national characters (#, @, and $). Optionally the mixed case password option can be selected for RACF, beginning with z/OS V1R7, which prevents RACF from folding alphabetic lowercase characters to uppercase. Note that the use of mixed case passwords also implies that the application itself is not folding the password to uppercase before passing it to RACF for verification.
Alternatives to password authentication - password phrase RACF supports the password phrase starting with z/OS V1R8. A password phrase is also kept in the user profile, can have a maximum length of 100 characters and has syntax rules hardcoded in RACF: The user ID (as sequential upper case characters or sequential lower case characters) is not part of the password phrase. At least 2 alphabetic characters are specified (A - Z, a - z). At least 2 non-alphabetic characters are specified (numeric characters, punctuation, special characters). No more than 2 consecutive characters are identical.
The minimum length of the password phrase that RACF supports is 9 characters at z/OS V1R9. However. RACF allows users to specify a password phrase of 9 to 13 characters only if the new password phrase exit (ICHPWX11) is installed (implicitly for a user-designed additional verification of this short password phrase format and syntax).
Applications call the same RACF service whether the entity to verify is a password or a password phrase. RACF recognizes from the passed parameters whether a password or a password phrase has to be verified.
Alternative to password authentication - RACF PassTicket PassTickets are dynamically generated password substitutes, in the form of an 8-character long value, that can be generated either by RACF or a PassTicket generator client program. In either case a secret cryptographic key must be shared between the generating entity and the instance of RACF that will later evaluate the PassTicket. Once generated for a client application, the PassTicket flows to the z/OS server application as a traditional password.
Chapter 4. Focusing on the z/OS Security Server (RACF) 45 Note that the z/OS applications are not PassTicket-aware and pass the PassTicket for verification to RACF as if it were a regular password. RACF tries to match the PassTicket to the user’s actual password in the USER profile and fails in that case. It then tries, if proper setup has been made in the RACF data base, to validate the passed value as a proper PassTicket. Successful validation results in the user being authenticated and an ACEE being
created.
The RACF PassTicket has very specific characteristics: It has a limited lifetime, which requires the password generator platform and the receiving z/OS to be clock-time synchronized. The PassTicket validity time window is fixed at plus or minus 10 minutes with respect to the PassTicket generation time. Unless specified otherwise in the validating RACF instance, a PassTicket can only be used once, that is, the same binary value cannot be replayed for authentication by the same user within the specified ticket lifetime.
4.2.2 User identity mapping for digital certificates
The RACF database is the IBM-recommended repository for X.509 certificates and private keys that applications running in the z/OS instance may need. They are managed using the RACDCERT RACF administration command that allows operations such as generating keys and certificates in the RACF data base, or importing keys and certificates into the RACF data base, or exporting keys and certificates out of the RACF data base. With the RACDCERT command the RACF database can be used to accomplish the following: Contain RSA or DSA key pairs and the related digital certificates owned by the local z/OS server and client applications. Contain information for mapping a remote client certificate to a local z/OS RACF UserID. Once an application has received a partner’s certificate and has authenticated it (remember that RACF is not involved in the authentication process for a digital certificate) the application then passes the certificate to RACF requesting a mapped-to RACF userID.
The certificate-to-userID mapping can be achieved by one of the following: Pre-installing a copy of the expected partners’ certificates in the RACF data base, implicitly setting up a pointer to the RACF USER user profile they should map to. In that case RACF checks if the passed-to certificate is one of those certificates residing in the data base and returns the corresponding userID. This is always a one-to-one mapping between a given certificate and a given RACF userID. Setting up in RACF criteria for a dynamic analysis of the passed-to certificate (a RACF mechanism called “Certificate Name Filtering”). The filtering criteria address the contents of the certificate subject’s name and issuer’s name fields. The RACF userID which is returned as the result of this analysis depends on what the contents of these fields are. There are two important characteristics of this mapping technique: – There is no need to have the passed-to certificate reside in the RACF data base. – The filtering criteria allow to map many certificates (provided they have common strings of attributes and values in the subject’s or issuer’s name) to one single RACF userID.
Note that in either case individual accountability is preserved because the individual user-identifying information from the X.509 digital certificates is retained in the ACEE credential and is included in any auditing (or logging) records created by the process.
46 Designing for Solution-Based Security on z/OS Additional information on RACF certificate identity mapping is given in 7.1.3, “Identity mapping in z/OS” on page 105. Certificate Name Filtering is further discussed in z/OS Security Server RACF Security Administrator’s Guide, SA22-7683.
4.2.3 User identity mapping for Kerberos tickets
Specific profiles (profiles in the KERBLINK class) can be defined in the RACF data base that map a Kerberos principal name to a RACF userID. z/OS applications that are Kerberos-enabled have to proceed with the authentication and parsing of the Kerberos ticket they receive and then pass the Kerberos principal name in the ticket to RACF for userID mapping.
RACF users who are also defined as Kerberos users in their USER profile have KERBLINK profiles automatically generated for them.
4.2.4 Resource access control
As explained in 4.1.1, “The RACF infrastructure for identification, authentication, and authorization” on page 42, the RACF administrators, or resource owners, define and maintain resource profiles in the RACF data base. With the Multilevel Security (MLS) security model activated and operating in its normal way, resource profiles are administered only by RACF administrators.
Depending on the nature of the resource they protect, resource profiles belong to a RACF “class” of resource.
The resource profile contains a list (the “access list”) of RACF users, or groups of users, permitted to access the resource and the access level they can use for this access. RACF allows to specify five access levels for a resource, which are intended to give granular control to the users: NONE READ UPDATE (which implicitly includes the READ privilege) CONTROL (which includes READ and UPDATE privileges) ALTER (which includes READ, UPDATE, and CONTROL privileges) EXECUTE - This access level is reserved for the protection of programs. A program protected in RACF as a resource with the EXECUTE access level can be executed by users permitted to access the resource but cannot be read or copied by them.
The resource profile also contains the access level given by default to the resource (the Universal Access - UACC). We address these access levels in the important note below.
To check access of a user to a resource, the resource manager calls RACF specifying the location of the ACEE control block (so that user information can be retrieved), the resource class, the resource name (the profile name in this class), and the desired access level. RACF then searches the designated resource profile for the specified userID in the resource access list, or whether the UACC access level is sufficient to grant the required access. RACF gets back with return code and reason codes to the resource manager indicating the result of the search. It is then up to the resource manager to grant or deny the access to the user application.
Chapter 4. Focusing on the z/OS Security Server (RACF) 47 This access control mechanism is also one of the base mechanisms that insure integrity of data and programs in z/OS by controlling requests ranging from copying programs or data up to modifying programs and data. The z/OS components are themselves protected by RACF access control and only authorized system programmers can access and maintain the z/OS programs.
Important: It is important to understand how “neutral” RACF is in making access control decisions. RACF can be thought of as just a special purpose database; administrators define information in the data base and RACF provides “advice” based on this information to the requesting z/OS component.
Likewise, a resource defined in RACF is meaningful only to the resource manager. For instance, RACF is set up to manage many classes of resources in support of z/OS or other products’ resource managers: the resource data set is meaningful to z/OS DFSMS, the network resources in the SERVAUTH class are meaningful to the z/OS Communications Server, and so forth. The users can define and administer their own classes of resources in RACF, should they need them for their home-grown, or purchased, resource managers.
The access levels in RACF are also a matter a convention. They were originally specified to deal with MVS data set protection (hence the READ and UPDATE privilege) and specific access constraints associated with these data sets. The access levels can be thought of today at a more abstract level, a READ access level having a different meaning depending on the resource it pertains to.
Back to Multilevel Security (MLS) In z/OS, MLS is the implementation of a security model called Mandatory Access Control (MAC). By contrast, the RACF security model that we discussed is called Discretionary Access Control (DAC). MAC is mainly used by governmental or military organizations, although it can prove to be quite helpful for commercial organizations as well.
DAC is always in operation and the activation of MAC, or MLS in RACF, is optional. MAC makes the first access control decisions based on a compartmentalization of resources and users. With MLS, users and resources are given attributes referring to their hierarchical security level and the non-hierarchical category (or compartment) they belong to. Security levels and categories are grouped together into constructs called security labels, defined in RACF with the SECLABEL class of profiles. When MLS is active, resources and users should be given a security label that the MAC mechanism evaluates when it comes to control access. If the evaluation shows proper user privilege, as specified by the security labels, then the DAC mechanism, that is, the exploitation of the access list and UACC in the resource profile in the traditional way, is invoked. The request is immediately denied if the resource’s and requestor’s security labels are evaluated as incompatible.
Notes: MLS can be set up for a subset of the total user community. A large or small number of resources can be protected with security labels, then the same labels can be assigned to users. Applications need to be MLS-enabled so that they can provide the proper security label-related information when calling RACF.
48 Designing for Solution-Based Security on z/OS 4.2.5 X.509 digital certificate management
The RACF database can contain specific profiles that are actually X.509 digital certificates and their private keys (if it is provided with the certificate) in the DIGTCERT class of profiles. It can also contain an aggregation of these keys and certificates, called RACF key rings which are actually profiles in the DIGTRING class. And finally it can contain name filtering criteria, as explained in 4.2.2, “User identity mapping for digital certificates” on page 46, in the DIGTNMAP and DIGTCRIT classes of profiles.
All these profiles are managed using the RACDCERT RACF administration command. Therefore, using the RACDCERT command, a RACF administrator can do the following: Generate RSA or DSA key pairs, the associated X.509 certificates, or certificate requests. Define key rings to be owned by applications. The certificates and keys aggregated into a key ring are thus made available to specific applications, if desired. Import or export keys and certificates in miscellaneous standardized formats (PKCS#7, PKCS#12, and so on). Optionally, if the certificate private key is an RSA key, it can be stored, for maximum protection, in the ICSF Public Key Data Set (PKDS). Establish mapping information for partners’ certificates: – By importing the partners’ certificates into the RACF data base and by thus setting pointers to the mapped-to RACF userID. – By defining the Certificate Name filtering criteria in the DIGTNMAP and DIGTCRIT profiles.
The following X.509 V3 certificate extension fields are supported when generating key pairs and certificates with the RACDCERT command: subjectKeyIdentifier authorityKeyIdentifier KeyUsage basicConstraints subjectAltName issuerAltName
4.2.6 RACF as a Kerberos user registry
RACF can be set up to act as a Kerberos user registry when z/OS is providing Kerberos Key Distribution Center services. In this case the Kerberos users belonging to the z/OS KDC realm must have a USER profile defined for each in the RACF data base. The RACF administrators then extend their profile by defining a KERB segment that describes the Kerberos attributes of the user, including the user’s Kerberos secret key.
4.2.7 Remote security services via the z/OS LDAP server
RACF can provide remote security services that are requested via the LDAP protocols. Information on specific services are given in 4.5.4, “RACF remote services at z/OS V1R8” on page 64. RACF itself is not LDAP-aware. It is up to the SDBM and ICTX LDAP backends to convert the LDAP requests into an invocation of relevant RACF functions via macro instruction or callable service.
Chapter 4. Focusing on the z/OS Security Server (RACF) 49 4.2.8 Support of the J2EE security model
RACF provides this support by hosting the roles membership information that the J2EE technology uses to control access to beans and servlets. J2EE principals are members of lists of users, or members of user groups appearing in the list, that are actually access lists to sets of privileges called “roles”. The J2EE runtime environment checks whether the request for execution of a bean or a servlet is issued by a J2EE principal (that is, user) in the required role. The required roles are specified at deployment time of the application.
The options exist in WebSphere Application Server for z/OS to query the J2EE roles defined in an XML file, or in a Custom User Registry, or in an LDAP directory, or in the RACF database. For the latter option the RACF administrator has to define the J2EE roles in the EJBROLE class of profiles, each profile in the class being a role as specified during deployment. It also implies that a J2EE principal has to be a RACF userID because the list of J2EE principals in the role actually consists of entries in the access list of the EJBROLE profile.
Figure 4-2 demonstrates the process of identification, authentication, and authorization supported by RACF for WebSphere Application Server for z/OS.
Request
http/https Web / EJB Container RMI/IIOP Servlet execution or EJB RunAs other 1 principal beans is principal in role ? declarative or programmatic Authentication/ Mapping 2 3 Authorization to Role SAF
USER profile ejbrole profile access list APPLDATA=role_surrogate
Can also be XML, CUR or TAM
RACF userID becomes the Java Principal Can also be LDAP or CUR
Figure 4-2 RACF support for J2EE roles
1. The J2EE user sends a request to WebSphere Application Server for z/OS. 2. The caller authenticates by means supported by WebSphere Application Server and RACF. These means are basic authentication with userID and password or PassTicket or digital certificate with RACF identity mapping. On a successful authentication, and
mapping if required, the RACF userID becomes the authenticated J2EE principal. 3. To check whether the principal is in the right role, WebSphere Application Server sends a request for verifying permission of the J2EE principal (RACF userID) to the EJBROLE profile.
50 Designing for Solution-Based Security on z/OS
Note: A more detailed description of J2EE authentication and authorization mechanisms is given in Chapter 9, “WebSphere Application Server for z/OS and Web Services Security
basics” on page 155.
4.3 RACF auditing
Because RACF provides a single focal point for authentication and authorization through the SAF interface, it also provides a single point of collection for security information that together creates the auditing trail of security events. Audit data is essential for ensuring that the customer’s installation security policy is properly followed.
There are two types of audit data to consider: Static data in the RACF data base such as specific contents of resource profiles like the UACC value, the access list, and the logging options Dynamic auditing data as generated by RACF when detecting events that match requirements for logging
4.3.1 The RACF auditing infrastructure
Here we address the infrastructure in place with RACF that makes it possible to capture and exploit data to eventually be used to audit the security environment and security events in z/OS.
Auditing of static security data in z/OS The Data Security Monitor (DSMON) is a software tool that comes with z/OS and is used to generate reports containing information about the security environment created in RACF for z/OS applications. A DSMON report provides information about the following: Characteristics of the system environment where DSMON is executed RACF group structure Programs specified in the Program Property Table (PPT) Programs specified in the RACF Authorized Caller Table RACF Class Descriptor Table RACF exits RACF Global Access Checking Table RACF Started Procedures Table RACF User Attribute RACF User Attribute Summary Selected data sets
Dynamic logging of security information by RACF In this section we focus on the dynamic data that RACF generates and the tools that are available to exploit it. The information is captured in SMF records and audit functions are available to specify what specific information has to be collected by RACF to eventually be inserted in these SMF records.
Chapter 4. Focusing on the z/OS Security Server (RACF) 51 RACF always logs information about certain events because knowing about occurrences of these events is essential to an effective data security infrastructure. The events that RACF always logs are: Every use of the administration commands that specify RACF operating options (SETROPTS) or change the status of a RACF data base (RVARY). Every time a request for authentication fails. Every time the console operator grants access to a resource as part of the failsoft processing performed when RACF is inactive. When a user not defined as a z/OS UNIX System Services user tries to dub a z/OS process as a UNIX process. When an unauthorized user tries to mount or unmount a UNIX file system. When MLS is active and a user successfully sets or resets his write-down mode, or fails attempting to do so because the user does not have the write-down privilege (write-down is the capability of declassifying data, security-wise, which is prevented by default when MLS is active).
RACF can optionally log other events. Optional logging is under the control of either a resource profile owner or the auditor, as explained in 4.3.2, “RACF auditing controls” on page 53.
The auditing trail consists of specific SMF records. The following facilities are available in RACF for logging auditing information: Audit control functions that enable the user to specify the information RACF is to record (or log). Logging routines that record the information the user has specified when RACF detects events that match the auditing criteria. The R_auditx callable service is available in z/OS V1R7 for z/OS components that require the ability to trigger, by themselves, logging of security-relevant events.
Utilities are available to extract and format the logged auditing information: The RACF SMF data unload utility, which converts SMF records into data formats that can be used by a relational database manager, or as XML data which can be easily viewed by XML supporting software products, such as a Web browser. The DFSORT™ ICETOOL, which generates reports from the information provided by the RACF SMF data unload utility and by the RACF database unload utility. The RACF report writer, which generates tailored reports based on the information the users have directed RACF to log.
SMF records that report security-relevant events detected by RACF or applications The following record types are used by RACF to log security-related information: Type 80 This record is produced during RACF processing and logs the following events: – Unauthorized attempts to enter the system – Authorized attempts to enter the system – Authorized accesses or unauthorized attempts to access RACF-protected resources – Authorized or unauthorized attempts to modify profiles in the RACF database There are no subtypes for record type 80.
52 Designing for Solution-Based Security on z/OS Type 81 This record is produced at the completion of RACF initialization and when changing RACF options with the SETROPTS command. There are no subtypes for record type 81.
Type 83 This record is produced during RACF processing or on request by z/OS components that use the R_auditx callable service to log security-related data by themselves. There are several subtypes for type 83: • Subtype 1 - This is a RACF processing record for auditing data sets that are affected by a RACF command that caused the security label to be changed. • Subtype 2 - This subtype contains auditing data provided by Enterprise Identity Mapping (EIM). • Subtype 3 - This subtype contains auditing data provided by the z/OS LDAP server. • Subtype 4 - This subtype contains auditing data provided by a client application using the remote auditing service. The remote auditing service is explained in “Remote auditing” on page 66.
The contents of these records are described in z/OS Security Server RACF Macros and Interfaces, SA22-7682.
4.3.2 RACF auditing controls
When it comes to specifying auditing controls, RACF makes a clear distinction between controls available to regular users or administrators, and RACF users with the AUDITOR attribute.
Owner-controlled logging Owners of resources can specify, in the resource profile, when defining or by modifying the profile, what types of access results to log (successes, failures, or both) and what level of access to log (READ, UPDATE, CONTROL, or ALTER). The following commands can be used by resource owners, who can also specify that no logging is to occur for an access that is a success or failure:
RALTER class ( profiles ) AUDIT(access-attempt [(audit-access-level)] )
ALTDSD profile AUDIT(access-attempt [(audit-access-level)] )
Access attempts results to log The following options are available: ALL - Specifies that both detected authorized accesses and detected unauthorized attempts to access the resource will be logged. FAILURES - Specifies that detected unauthorized attempts to access the resource will be logged. NONE - Specifies that there will not be any logging to be done for accesses to the resource. SUCCESS - Specifies that authorized accesses to the resource will be logged.
audit-access-level The levels that can be specified are: ALTER - To log ALTER access-level attempts only. CONTROL - To log access attempts at the CONTROL and ALTER levels.
Chapter 4. Focusing on the z/OS Security Server (RACF) 53 UPDATE - To log access attempts at the UPDATE, CONTROL, and ALTER levels. READ - To log access attempts at any level. This is the default value if no access level is specified.
Auditor-controlled logging Auditors can direct RACF to log additional events. These events are: Changes to any RACF profiles All RACF commands issued by users who either had the SPECIAL attribute, or gained authority to issue the command because they had the group-SPECIAL attribute All unauthorized attempts to use RACF commands All RACF-related activities of specific users All accesses to resources (data sets and general resources) that RACF allows because the user has the OPERATIONS or group-OPERATIONS attribute All accesses to specific data sets All accesses to specific general resources All accesses to resources protected by specific profiles in the SECLABEL class All accesses to a specified class of resources at an access level indicated on the LOGOPTIONS keyword of the SETROPTS command Selected events in related MVS transactions z/OS UNIX System Services events
The auditor can use the UAUDIT or NOUAUDIT operand on the ALTUSER command to log all RACF-related activities for a specific user. When the control is set, RACF logs the following events: All RACF commands that the user issues All additions, changes, or deletions that the user makes to the RACF profiles All attempts that the user makes to access RACF-protected resources, except those authorized by global access checking
Adding to the owner’s specified auditing options Users with the AUDITOR attribute can specify additional logging that supersedes the owner’s logging specification for a specific resource by adding audit controls to the resource profile. This is done by the auditor for specific resource profiles by specifying the GLOBALAUDIT operand in the resource profile. In that case the owner’s logging specifications for the resource profile are not changed, the AUDITOR’s logging options only add to them. That is, regardless of the value specified in GLOBALAUDIT, RACF always logs all access attempts specified on the AUDIT operand.
Overriding the owner’s specified auditing options Users with the AUDITOR attribute can also audit access attempts to resources in specified classes according to the auditing level they specify in this command:
SETROPTS LOGOPTIONS (auditing-level (class-name ...) ...)
The auditing-level can be the following: ALWAYS All access attempts to resources protected by the class are audited. This overrides the auditing specifications in resource profiles.
54 Designing for Solution-Based Security on z/OS NEVER No access attempts to resources protected by the class are audited (all auditing is suppressed). This overrides auditing specification in the resource profiles. SUCCESSES
All successful access attempts to resources protected by the class are audited. This is done in addition to whatever is specified in the resource profiles. FAILURES All failed access attempts to resources protected by the class are audited. This is done in addition to whatever is specified in the resource profiles. DEFAULT Auditing is controlled by whatever auditing options are specified in the profile protecting the resource. You can specify DEFAULT for all classes by specifying an asterisk (*) with DEFAULT.
Auditing of z/OS UNIX resource access Auditing of access to z/OS UNIX resources (files and directories) is controlled by audit flags in the File Security Packet (FSP) associated with the file or directory and the status of specific classes in RACF that are intended to control auditing of z/OS UNIX resource access.
Background information about the protection of the z/OS UNIX resources can be found in the IBM Redpaper z/OS UNIX Security Fundamentals, REDP4193.
Auditing flags in the File Security Packet The following accesses can be audited: read, write, or execute/search access to the file or directory. They can be audited for: Successful access Failures, that is, access violations All (both successes and failures) None
The auditing criteria are specified in two sets of audit controls for each z/OS UNIX resource: The “File Owner” flags - The user must be a superuser or the owner of the file (or the directory) to specify these user audit options. The “RACF Auditor” flags - The user must have the RACF AUDITOR attribute to specify these auditor options.
Data in audit records are collected based on the combined owner and AUDITOR settings.
Resource classes in RACF that control UNIX resources auditing Seven predefined classes are defined in RACF to control z/OS UNIX resource auditing. No profiles can be defined in these classes; they are intended to be used only as parameters for SETROPTS LOGOPTIONS. These classes do not need to be active for access control checking and auditing of z/OS UNIX resources to occur.
DIRSRCH Controls auditing of directory searches DIRACC Controls auditing for access checks for read/write access to directories. FSOBJ Controls auditing for all access checks for file system objects except directory searches via SETROPTS LOGOPTIONS, and controls auditing of creation and deletion of file system objects via SETROPTS AUDIT.
Chapter 4. Focusing on the z/OS Security Server (RACF) 55 FSSEC Controls auditing for changes to the security data (FSP) for file system objects. PROCESS Controls auditing of changes to the UIDs and GIDs of processes and changing of the thread limit via SETROPTS LOGOPTIONS, and controls auditing of dubbing, undubbing, and server registration of processes via SETROPTS AUDIT. PROCACT Controls auditing of functions that look at data from or effect other processes. IPCOB Controls auditing and logging of IPC security checks.
The SETROPTS LOGOPTIONS command is used to specify logging options for all the classes associated with z/OS UNIX System Services, that is, the auditing levels of ALWAYS, NEVER, SUCCESSES, FAILURES, and DEFAULT.
4.3.3 Exploitation of RACF auditing SMF records
RACF inserts a very large amount of data in an SMF type 80 record that can be exploited to build a very detailed auditing trail for security events detected by RACF. The main data items are: The record type Time stamp (time and date) Processor identification Event code and qualifier User identification Group name Authorities used to successfully execute commands or access resources Reasons for logging Command processing error flag Foreground user terminal ID Foreground user terminal level number Job log number (job name, entry time, and date) RACF version, release and modification number Security label of user
RACF uses event codes and event code qualifiers to give detailed information about the nature of the event that triggered auditing and also the RACF identity attached to the process that triggered the event, which is primarily the RACF userID but can also be accompanied by the X.500 name of the user as provided in a digital certificate, and the RACF groups the RACF userID is connected to.
This can be used by auditors to establish the user’s accountability for the event, that is, the capability of tracing activities on the protected system to a particular individual.
The RACF SMF Data Unload Utility The RACF SMF Data Unload Utility (IRRADU00) enables installations to create a sequential file from the security-relevant audit data. The sequential file can be used in several ways: viewed directly, used as input for installation-written programs, manipulated with sort/merge utilities, output to an XML-formatted file for viewing on a Web browser, or uploaded to a database manager (for example, DB2) to process complex inquiries and create installation-tailored reports. It is not intended to be used directly as input parameters for RACF commands.
The following SMF records are processed by the utility: Type 30 subtype 1 (Job initiation) and subtype 5 (Job termination) Type 80
56 Designing for Solution-Based Security on z/OS Type 81 Type 83
The utility creates a sequential file which, in addition to the traditional reports and tables produced, can also be directed as output to an XML-formatted file for viewing on a Web browser. The SMF Data Unload Utility output can be the following, as illustrated in Figure 4-3: Viewed directly Used as input to installation-written programs Manipulated with sort/merge programs Browsed as XML-formatted output The security-related SMF records extracted can be formatted as an Extensible Markup Language (XML) document. An audit report using XML can be distributed and analyzed on multiple platforms and operating systems. The advantages of using XML are: – A better view of the data, making it more readable than tabular forms – Different fonts can be utilized – A view of Audit data that can be tailored to the user’s environment
Raw SMF Record
5E29004A 4C060101 055FC9D4 F1F34040 40400003 00050000 00000044 00180001 00000000 00000000 00000000 00000000 00000000 00000000 0000005C 00280002 C8C2C2F7 F7F0F340 E5D3C640 40404040 40404040 40404040 C9D9D9C1 C3C5C543 00001000 00000002 00000030 0000002A 0000000F 00000000 00000000 00000D84 C9D9D9E4 D4C1D740 00001000 00000000 00000000 00000000 00000000 00000005 00000000 00000000 C9D9D9C7 D4C1D740 00001000 00000000 00000000 00000006 00000000 00000000 00000000 00000000 C9D9D9C7 E3E24040 00001000 00000007 00000000 00000000 00000000 00000000 00000000 00000000 C3D3C1E2 E2F44048 00000100 00000000 00000000 00000000 00000000 00000000 00000000 00000009 C3E2E5D3 D3C14040 00001000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ....
SMF SMF Unload Dataset
Tabular Representation XML tagged document
... ACCESS SUCCESS 20:06:10 1998-08-26 IM13 NO NO NO IBMUSER SYS1...
customformat HTML customformat DB2 Database
browsers b2b app
Figure 4-3 RACF SMF Data Unload Utility
For more details, refer to z/OS Security Server RACF Auditor’s Guide, SA22-7684-08
Chapter 4. Focusing on the z/OS Security Server (RACF) 57 4.4 Accessing RACF from Java applications
Java APIs are available that allow Java applications to manage RACF user and group profiles or to exploit RACF services.
4.4.1 Java API for RACF services in the IBM JDK
SAF classes are available since JDK™ V1.R4 that provide a set of security APIs. These APIs are implemented through Java classes wrapping z/OS UNIX Services. The z/OS UNIX Services are in turn handled by a Security Server for z/OS that implements SAF interfaces (such as RACF). The classes provided are: PlatformAccessControl PlatformThread PlatformSecurityServer PlatformAccessLevel PlatformReturned PlatformUser
The methods in these classes allow a Java application to: Check to see whether the Security Server or a specific security server class is active Extract the userID in effect for the current running thread Check the userID in effect for access rights to a resource Authenticate a userID and password Check if a userID is a member of a group Change a user's password
4.4.2 Java APIs in z/OS for RACF services
RACF PassTicket Java evaluation and generation Java applications can use, beginning with z/OS V1R7, the IRRPassTicket class to generate and evaluate RACF PassTickets. The IRRPassTicket class is delivered in z/OS in /usr/include/java_classes/IRRRacf.jar.
IRRPassTicket uses native methods (JNI™) to call the R_tickerserv and/or R_gensec RACF callable services to perform PassTicket operations. JavaDoc documentation for the IRRPassTicket is located in /usr/include/java_classes/IRRRacfDoc.jar, which must be copied to a workstation, uncompressed, and viewed with a Web browser.
The JSec (Java Security API) JSec is a Java interface to administer or query users and groups in RACF. It has been designed following these guidelines: Be a generic interface that could be used to query users and groups in other security repositories, as a “pluggable” implementation. It can be run on or off a z/OS platform.
It is built on commonly used objects and interfaces in JSDK. It is designed to be easily mapped to other interfaces to RACF user and group administration, such as the RACF administration TSO ADDUSER, ALTUSER, and CONNECT commands.
The JSec API is delivered in two jar files in z/OS, beginning with z/OS V1R9:
58 Designing for Solution-Based Security on z/OS /usr/include/java_classes/userregistry.jar /usr/include/java_classes/RACFuserregistry.jar
The API can be used by Java applications running on z/OS, or the jar file can be downloaded on any machine with a JVM™ and a TCP/IP connection and can be used by a Java application running on this machine.
Important: note that the Jsec API uses the z/OS LDAP server and the SDBM backend, as shown in Figure 4-4, to access the USER and GROUP profiles in the RACF database. The LDAP server can be the z/OS Integrated Security Services LDAP server or the IBM TDS. The SDBM backend is further explained in 3.2.3, “IBM Tivoli Directory Server for z/OS” on page 31.
Local or remote to z/OS
RACF Java JSec TCP/IP TCP/IP z/OS SDBM application JVM JNDI Users API LDAP Server backend Groups connections
Provided in z/OS HFS: /usr/include/java_classes/userregistry.jar /usr/include/java_classes/RACFuserregistry.jar
Figure 4-4 The Jsec API infrastructure
The Java ICTX API (RACF Identity Cache) The ICTX Java API is the primary interface for working with the z/OS Identity Cache. It is provided in z/OS and can be downloaded, if needed, from z/OS to another Java-enabled platform. The RACF Identity Cache is explained in “RACF identity cache” on page 67.
4.5 Accessing RACF using the LDAP protocol
The z/OS LDAP server supports providing access to RACF profiles or services to remote LDAP clients. The LDAP server must be running in the z/OS instance that hosts the target RACF system and the following backends are used, depending on the function requested by the client: The SDBM backend, which allows to access the USER and GROUP profiles in the RACF database, and to perform connection or removal of RACF users to or from RACF groups. The GDBM backend, which is used to indicate to an LDAP client that a change was made to a USER or GROUP profile, or to the connection of a user to a group, in the RACF database. The extended operation (EXOP) ICTX backend that interfaces with RACF for the Remote Authorization, Remote Auditing, and Identity Cache services.
RACF supports the “Password Enveloping” that allows an authorized LDAP client to securely extract a RACF user password out of the RACF database using the LDAP protocol.
Chapter 4. Focusing on the z/OS Security Server (RACF) 59 4.5.1 Administering the RACF users and groups through LDAP
The z/OS LDAP and RACF infrastructure which is used in that case is shown in Figure 4-5. It uses the LDAP server and the SDBM backend. Note that it is sufficient to activate the SDBM backend only to provide the required functions. The SDBM backend requires the user to authenticate, with an LDAP authenticated “bind”, with a RACF userID and password which are then verified by RACF. Once the user has been authenticated, the SDBM actually converts the client’s LDAP commands into RACF TSO commands, which are run with exactly the same RACF privileges as if the user were working from a TSO terminal. The responses are likewise converted so that they are issued in the proper LDAP syntax and format.
Note that there are no specific controls to access this function besides the user being successfully authenticated by RACF and owning the proper RACF privileges.
z/OS
TCP/IP LDAP RACF RACF SDBM Data LDAP client stack Schema Server base SSL/TLS
z/OS UNIX config
Figure 4-5 Administering RACF users and groups with LDAP
The equivalency between the LDAP and RACF commands is shown in Table 4-1.
Table 4-1 LDAP and RACF TSO commands LDAP TSO RACF commands commands
ldapadd ADDUSER ADDGRP CONNECT
ldapmodify ALTUSER ALTGRP
ldapdelete DELUSER DELGRP REMOVE
ldapsearch SEARCH LISTUSER LISTGRP
The LDAP schemas used in that case are fixed by IBM and are built-in in the LDAP server. The user only specifies the suffix of the LDAP objects distinguished names (the suffix is
60 Designing for Solution-Based Security on z/OS actually used by the LDAP server to point at the RACF directory tree). The RACF directory tree appears to the LDAP clients as shown in Figure 4-6 on page 61. There are three subtrees, all entries being at the same level in the three subtrees: The USER profile entries The GROUP profile entries The connection entries These are actually users-to-groups connections appearing as LDAP objects. An ldapadd of such an object is translated by the SDBM backend into a RACF CONNECT TSO command. Likewise an ldapdelete of a connection object will be issued as a REMOVE command to RACF.
SuffixDN (cn=RACFA, o=IBM,c=US) objectclass=racfBase
Profiletype=User Profiletype=Group Profiletype=Connect objectclass=racfprofiletype objectclass=racfprofiletype objectclass=racfprofiletype
racfid=XYZ111, racfid=GRP222,, racfuserid=XYZ111+racfgroupid=GRP222,, profileType=User,… profileType=User,… … … profileType=Connect,… … objectclass=racfUser objectclass=racfGroup objectclass=racfConnect and so on and so on and so on
Figure 4-6 z/OS LDAP RACF directory tree
4.5.2 LDAP Change Log for changes in RACF USER and GROUP profiles and users-to-groups connections
The z/OS LDAP GDBM backend is used to record changes that occur in a z/OS-managed LDAP directory—an LDAP Change Log. This includes changes to the “RACF directory” as well. In our case the entries in the GDBM directory provide LDAP clients with a quick look-up capability to detect any change that occurred in a RACF USER or GROUP profile or a user-to-group connection.
Once a change of interest is detected by the LDAP client, it can then pick up the changed data in RACF using an ldapsearch command against the SDBM backend.
The required z/OS LDAP infrastructure is shown in Figure 4-7. Note that the GDBM directory data can be held in HFS files (only available with the IBM TDS LDAP server) or alternatively into DB2 tables.
Chapter 4. Focusing on the z/OS Security Server (RACF) 61
z/OS
TCP/IP RACF RACF LDAP SDBM LDAP client stack Data Schema Server base
SSL/TLS GDBM HFS z/OS UNIX config zFS ACL
DB2 CHANGENUMBER=1202,CN=CHANGELOG Directory ACL Schema objectclass=CHANGELOGENTRY objectclass=IBM-CHANGELOG changenumber=1202 targetdn=cn=ken34,o=Your Company Contents of the changetime=20031002003951.302193Z GDBM change log changetype=ADD changes=objectclass: inetorgperson as seen by the cn: ken34 userpassword: *ComeAndGetIt* LDAP clientt sn: Morgan telephonenumber: 123-456-7890 ibm-entryuuid: 59290000-73D7-1F7B-94ED-40206404095
ibm-changeinitiatorsname=cn=dept68mgr,o=your company
Figure 4-7 z/OS LDAP GDBM Change Log infrastructure
The GDBM schema is fixed and is also built-in in the z/OS LDAP server. The directory tree suffix is also fixed and must be cn=changelog.
Change Log notification RACF is actually calling for the generation of a change log entry for events affecting the USER or GROUP profiles, or users-to-groups connections (RACF events notification for changes to GROUP profiles or group membership is available beginning with z/OS V1R8).
The generation of change log entries is controlled by the following profiles in the RACFEVNT class. These profiles act as a “switch” in that if the RACFEVNT class is active, and the appropriate profile (discrete or generic) is defined, then LDAP change log entries are created for the corresponding event types on a system-wide basis (provided that the GDBM backend is in operation in the system). NOTIFY.LDAP.USER This profile controls the generation of a change log entry for the following events: – Password changes, regardless of the command or method used – Updates to a user’s revoke status regardless of the command or method used – Users added using the ADDUSER command – User modifications made using the ALTUSER or PASSWORD command – Users deleted using the DELUSER command
62 Designing for Solution-Based Security on z/OS NOTIFY.LDAP.GROUP This profile controls the generation of a change log entry for the following events: – Groups added using the ADDGROUP command – Group modifications made using ALTGROUP command – Groups deleted using the DELGROUP command NOTIFY.LDAP.CONNECT This profile controls the generation of a change log entry for the following events: – Group membership changes made using any of the following commands: • ALTUSER, only when issued with the GROUP, UACC, or AUTHORITY operand • CONNECT •REMOVE – Users established in their default groups using the ADDUSER command
4.5.3 RACF Password Enveloping
RACF Password Enveloping is a function available beginning with z/OS V1R6 that allows authorized LDAP clients to extract the new passwords of selected users from the RACF database, using the LDAP protocol. These passwords can in turn be stored in LDAP user registries by the extracting client. The overall process is shown in Figure 4-8 on page 63, where the new user password is stored, as usual, in the user’s profile with non-reversible encryption, but an additional copy of this password is also kept, encrypted with a reversible process, in the RACF database and appears in the “RACF directory” as the SDBM-specific racfPasswordEnvelope LDAP object. At the same time a GDBM entry is created, indicating a password change in the user profile with the availability of a password envelope designated by the arbitrary chain of characters “comeAndGetIt”.
Authorized LDAP clients, which were inspecting the GDBM change log directory, can then authenticate to RACF and extract this object with an ldapsearch command. The password is then delivered as a PKCS#7 envelope, which is encrypted by a combination of symmetric (Triple-DES) and asymmetric (RSA) processes.
dn: changenumber=13,cn=changelog objectclass: top objectclass: changeLogEntry objectclass: ibm-changelog changenumber: 13 targetdn: racfid=JOEUSER,profiletype=user,o=ibm,c=us changetype: modify changetime: 20030729123000 Changes: replace: racfPassword racfPassword:*ComeAndGetIt* ibm-changeinitiatorsname: racfid=JOEADMIN,profiletype=user,o=ibm,c=us Selected user changes password ldapsearch Search for RACF LDAP event Change log entry LDAP client new log entries notification In the GDBM backend
ldapsearch Get the RACF SDBM backend racfPasswordEnvelope DB object
Password envelope Prepare password ldapmodify to target for propagation directories to target directories
Figure 4-8 RACF Password Enveloping
Chapter 4. Focusing on the z/OS Security Server (RACF) 63 The RACF Password Enveloping LDAP client Note that the LDAP client is expected to execute a somewhat sophisticated process, such as: 1. Inspecting the GDBM change log directory and detecting changes to RACF users’ passwords.
2. Binding and authenticating to the SDBM backend, and getting the racfPasswordEnvelope object. 3. Retrieving the clear password from the PKCS#7 envelope and reformatting it as a userPassword object for propagation to the LDAP directories to be synchronized (racfPasswordEnvelope is an object specified for the SDBM use only and is not a known attribute for non-z/OS LDAP implementations). 4. Proceeding with the ldapmodify that will install the password in the target LDAP directories. It is obviously expected here that those communications with the target LDAP directories be protected with SSL or TLS.
Users can develop this LDAP client by themselves. However, the IBM Tivoli Directory Integrator (ITDI) is such a ready-made LDAP client. ITDI is a powerful and flexible integration toolkit for integrating different flows or repositories of data such as DB2 tables, LDAP directories, HTTP flows, and so on. ITDI comes with, among many other things, all the functions described above already pre-installed.
RACF controls of Password Enveloping For password enveloping to work, RACF has to have its own RSA key pair, along with the digital certificates of the authorized LDAP clients. These clients have to “bind” to the SDBM backend by presenting a RACF userID and password and must therefore be defined in the RACF database.
The following RACF profiles are used for fine controls of the function: PASSWORD.ENVELOPE in the RACFEVNT class RACF password owners who are given READ access to the PASSWORD.ENVELOPE profile are eligible to have their password enveloped. The cryptographic algorithms to use for creating the envelope are also indicated in the APPLDATA field of the profile. IRR.ADMIN.EXTRACT.PWENV in the FACILITY class This profile gives permission to specific authenticated users to retrieve the password envelopes. The RACF userIDs of the LDAP clients are therefore expected to be in the access list of this profile.
4.5.4 RACF remote services at z/OS V1R8
Three services provided by RACF on z/OS are made available to off-z/OS applications. They are accessible to these remote applications via the LDAP protocol and require to have the IBM TDS LDAP server running on the z/OS that hosts the target RACF instance, with the ICTX backend active. The three services available in z/OS V1R8 are: Remote authorization Remote auditing RACF identity cache
The ICTX backend, which is delivered with the IBM TDS for z/OS, is the interface between the remote requestors and RACF, as shown in Figure 4-9 on page 65. Note that these remote services do not use LDAP standard commands but instead exploit the LDAP extended operations (EXOP) capability of the IBM TDS server.
64 Designing for Solution-Based Security on z/OS There are two requirements on the LDAP client that connects a remote application to these services: The LDAP client must support using LDAP extended operations. It must also support the Distinguished Encoding Rules (DER) encoding of the data exchanged with the IBM TDS server.
The ICTX backend has a suffix fixed by IBM: cn=ictx, and always requires an authenticated LDAP bind by the application calling the service. The authenticated bind is done using a distinguished name that contains a RACF userID in the format indicated below, along with a RACF password: DN: racfid=
backends z/OS
TCP/IP SDBM LDAP client stack LDAP V3 z/OS LDBM UNIX Remote auditing
GDBM Remote authorization ds.conf Identity Cache TDBM
EXOP ICTX
# ICTX extended operations support section Database ictx ITYBIC31 suffix « cn=ictx »
Figure 4-9 RACF remote services infrastructure
Remote authorization This service allows authorized off-platform clients to query a z/OS system to check a user’s authorization to a resource. This requires the following userIDs to be defined in RACF: The userID to be used by the remote application performing the authenticated bind to the LDAP server The userIDs that correspond to the remote application users that will be the subjects for the authorization checks by RACF
And obviously there will be RACF profiles that define the resources that the remote application is going to check access to. In most of the cases, it is expected that these resources not be z/OS resources, but resources which are meaningful to the remote application only, specified by agreement at application deployment time with the RACF administrator. There is, however, a foreseen use case where these resources could be profiles in the EJBROLE class for remote authorization checking by a J2EE application server.
The ICTX backend issues the RACROUTE REQUEST=AUTH macro instruction on behalf of the remote application, to test the authorization of the remote user to the RACF resource, using the parameters passed via LDAP with the call for remote authorization, and responds by sending back to the requestor the RACF return and reason codes resulting from the authorization request. Figure 4-10 on page 66 illustrates this process, where the remote application authenticates with the RACF userID APPLSRVR and requests an authorization
Chapter 4. Focusing on the z/OS Security Server (RACF) 65 check for the RACF user REMOTUSR, actually the RACF userID arbitrarily given to the remote end user.
Note that access to the remote authorization service is protected by the profile IRR.LDAP.REMOTE.AUTH in the FACILITY class of profiles, and the RACF userID of the remote application authenticating to LDAP must be permitted to this resource.
LDAP authenticated bind with DN: racfid=APPLSRVR,cn=ictx
Remote Remote IBM TDS ICTX user application LDAP For z/OS backend
SAF RACROUTE
RACF DB
APPLSRVR
REMOTUSR ? Remote resource
IRR.LDAP.REMOTE.AUTH SMF auditing Of accesses
Figure 4-10 Remote authorization
Remote auditing This service allows authorized off-z/OS clients to remotely log security events they have detected as RACF SMF records. The purpose of this service is to provide a centralized auditing trail on z/OS that includes security events happening both in z/OS and outside of z/OS.
As for remote authorization, remote auditing is performed via the ICTX backend which receives parameters sent by the requesting client application and uses them to invoke the R_auditx RACF callable service. The R_auditx service in turn generates an SMF type 83 subtype 4 record that contains the requestor-provided information.
Figure 4-11 on page 67 illustrates the process flow of the remote auditing service. Note that the remote auditing service is protected by the profile IRR.LDAP.REMOTE.AUDIT in the FACILITY class of profiles. The access to the R_auditx callable service is also protected by the IRR.RAUDITX profile in the FACILITY class. This time the LDAP server started task RACF userID must be permitted to the resource because it is the identity the ICTX backend runs under.
66 Designing for Solution-Based Security on z/OS
LDAP authenticated bind with DN: racfid=APPLSRVR,cn=ictx
Remote IBM TDS ICTX application LDAP For z/OS backend
R_auditx Callable service
RACF DB
APPLSRVR SMF type 83 IRR.LDAP.REMOTE.AUDIT Subtype 4
LDAPSRVR
IRR.RAUDITX
Figure 4-11 Remote auditing
RACF identity cache The RACF identity cache is an infrastructure and a remote service provided to support establishing end-to-end accountability of requests initiated outside of z/OS, that is, managing to keep track of the identity of the end user who triggered a process chain that eventually ends up accessing resources in z/OS.
In many configurations today, where a process chain is started on non-z/OS applications, the end user is properly authenticated by the upstream remote application but the identity is not propagated because the remote application forwards the request to the downstream z/OS application. Instead, in many cases, the remote application authenticates itself to z/OS using a generic RACF userID, that is, the same z/OS identity is always reused whoever the actual end user is. This results in a loss of the initial requestor accountability in the z/OS auditing trail.
Figure 4-12 on page 68 describes the infrastructure of the RACF identity cache.
Chapter 4. Focusing on the z/OS Security Server (RACF) 67
Extended ACEE to Auditing Regular ACEE +Distributed identity Optional identity + Registry name Mapping (EIM or other) + Host name + Authentication mechanism Distributed Application Identification information Identity Cache LDAP 1 EXOP Java API or R_cacheserv User Identified and 2 authenticated 5 in a distributed security 4 context Identity Context Reference (ICR) ACEE Java API Java RACROUTE REQUEST=VERIFY,ENVIR=CREATE 3 z/OS server application
ICR passed as basic authentication to z/OS application z/OS
Distributed identity domain SAF identity domain End-To-End user accountability
Figure 4-12 RACF identity cache
In Figure 4-12 an end user is authenticated by a remote application. It is expected that to exploit the z/OS identity cache the remote application is to use a Java API that is provided as jar files in z/OS V1R8. This API can be downloaded onto the remote platform and will create an LDAP connection to z/OS.
As for the other remote services that we mentioned, it is necessary to run the IBM TDS LDAP server and the ICTX backend in z/OS, and the remote application has to provide a valid RACF userID and password to ICTX.
The Identity Cache implementation exploits the RACF cache facility made available in z/OS V1R3, which received some improvements in z/OS V1R8. The RACF cache facility is in essence a dataspace managed by RACF where applications can put data, or retrieve data from, using the RACF callable service R_cacheserv. The Java API provided in z/OS V1R8 can also be used, instead of the R_cacheserv callable service, by z/OS local Java applications to store and retrieve cache data.
The process is as follows: 1. The remote application has proceeded with the identification and authentication of the remote user and uses the Java API to store into the RACF identity cache the following set of information: – The name of the user who was authenticated. It may be used as the source user in an identity mapping operation to be performed through the z/OS EIM interface, if EIM is available and properly set up. – The name of the user registry where the remote user is registered.
68 Designing for Solution-Based Security on z/OS – The mechanism used to authenticate the user. – The DNS name of the host system where the user was authenticated. – The security label associated with this user, if any. – Implementation-specific data. This set of information is actually sent, via the LDAP protocol, to the ICTX backend on z/OS, which manages to store the information in the RACF identity cache. 2. When storing information in the cache, the cache returns a dynamically generated reference number that can later be used to retrieve the stored information. The reference number is a 16-byte value that is passed to the remote application. It begins with two asterisk characters, and the last 8 bytes are a randomly generated binary number. 3. The remote application connects to the z/OS application to log on, and provides as a RACF userID the first half of the cache reference value (8 bytes) and, as a RACF password, the second half of the reference value. 4. There is no modification to be made to the z/OS application: it issues, as usual, a RACROUTE REQUEST=VERIFY macroinstruction to the SAF interface to verify the userID and password passed by the remote application. In z/OS V1R8, RACF recognizes, because of the two asterisks at the beginning of the userID, that the values passed by the z/OS application as userID and password are actually the two components of an identity cache reference value. 5. RACF extracts from the identity cache the identification information that was stored by the remote application and uses it to build an ICTX structure, which is chained to the ACEE created for the z/OS application thread. The effect of this chaining is that whenever RACF audit data has to be generated for the z/OS application, the generated SMF type 80 records will include the contents of the ICTX structure, that is, the identification information initially put in the identity cache—therefore maintaining accountability of the remote application’s end user as his/her identity appears in the z/OS auditing trail, along with the usual z/OS auditing information.
4.6 Complementing z/OS RACF
To use the RACF administration commands, or relevant ISPF panels, requires specific administration skills that many installations today find not to be synergistic with their other needs regarding the administration of their non-z/OS platforms, which, for most of them, can be administered via somewhat friendly graphical interfaces.
There is also now a need for regulatory compliance checking that goes beyond a simple verification of the system-level security, and makes it necessary to get both a focused and global view of the security setups and events that the RACF built-in reporting facilities do not provide.
The IBM approach to meet these additional requirements is to complement the RACF native user interface in z/OS with IBM Tivoli products that provide the following: Add-on functions for automating the administration and auditing of RACF data.
Monitoring, auditing, and compliance checking tools that consolidate RACF information with other systems information, in order to provide a view and rating of the security-related events and behaviors at the enterprise level.
Chapter 4. Focusing on the z/OS Security Server (RACF) 69 4.6.1 IBM Tivoli zSecure administration products
With the acquisition of the Consul company in January 2007, IBM Tivoli now owns the zSecure suite of products that perform both administration and auditing of mainframe external security managers, such as RACF. The zSecure administrative products consist of zSecure Admin, zSecure Visual, and zSecure CICS Toolkit, which are intended to assist RACF administration. The products share common components, including the Consul’s proprietary CARLA high-level programming language.
IBM Tivoli zSecure Admin This product consists of an ISPF-based user interface for the administration of RACF attributes. It runs entirely within z/OS without requiring any collaborating component on a distributed platform. zSecure Admin is intended to enable more efficient and effective RACF administration, using significantly less resources, and can be used to: Automate routine tasks to simplify administration. Identify and analyze problems to minimize threats. Merge databases quickly and efficiently. Display data from the active (live) RACF database. Integrate smoothly with IBM Tivoli zSecure Audit. Store non-RACF data to reduce organizational costs.
Figure 4-13 on page 71 shows an ISPF panel generated by zSecure Admin. zSecure Admin provides an interface that makes the RACF database look like a scrollable page of data (the panel in Figure 4-13 is actually the output of a RACF LISTUSER command). Using the analogy of an ISPF editor to present RACF profiles, the user can type over fields and make the changes in “what the user sees is what the user gets” mode. When the user makes a change to the panel and presses Enter, the proper RACF command is automatically generated.
70 Designing for Solution-Based Security on z/OS
Figure 4-13 IBM Tivoli zSecure Admin
IBM Tivoli zSecure Visual This product consists of a Windows-based user interface running on a Windows machine. It communicates, via TCP/IP, with a z/OS started task that performs limited RACF administration on behalf of the user. The intent of zSecure Visual is to reduce the need for sometimes scarce RACF-trained expertise through a Microsoft® Windows–based GUI that is used to drive RACF administration and can be used to: Decentralize RACF administration to optimize resources. “Scope down” administrative capabilities. Avoid the need for TSO/ISPF rollouts. Administer a live RACF database. Easily clone user templates.
Figure 4-14 on page 72 shows an example of graphical menus used by zSecure Visual, which displays a list of USER profiles in the RACF database with the REVOKED attributes. Actually, these profiles were obtained after triggering a search for USER profiles with the drop-down menu at the right bottom corner of the panel.
Chapter 4. Focusing on the z/OS Security Server (RACF) 71
Figure 4-14 IBM Tivoli zSecure Visual
4.6.2 IBM Tivoli zSecure CICS Toolkit
This product has two facets: It is a prebuilt administrative interface that runs as a CICS transaction in a CICS region, and it also provides a CICS API to allow applications to perform their own security functions. For example, if an application needed a reverification of user credentials when certain program constraints were met (such as funds transfer over a certain amount) the CICS Toolkit API could be used to drive this reverification.
Similarly, focusing on the same examples, the CICS Toolkit API could also be used to drive RACF audit capability. For instance, an SMF record can be generated to log the fact that this particular user executed a funds transfer above a certain amount.
Figure 4-15 on page 73 shows a prebuilt CICS RACF administration menu.
72 Designing for Solution-Based Security on z/OS
Figure 4-15 IBM Tivoli zSecure CICS Toolkit
4.6.3 Risk and compliance products
The IBM Tivoli risk and compliance products approach is to use agents in z/OS, and other operating systems, that provide information centrally collected by a focal point product that provides consolidated information to security administrators. Such focal point products are the IBM Tivoli Security Operations Manager and Tivoli Compliance Insight Manager. Note that both of these products are not running today on System z.
Tivoli Security Operations Manager The Tivoli Security Operations Manager collects real-time information, correlating the data with a view to finding policy violations or intrusion attempts, and reporting this. It is part of a Security Information and Event Management (SIEM) Tivoli platform.
Rather than having agents distributed to get the data, it acts as a central collection service and other components route data to it, such as from UNIX syslogs or intrusion detection software. To do so it uses conduits to receive SMTP messages, SNMP traps, and syslog data.
z/OS-specific information is provided by the zSecure Alert product that runs in z/OS, as shown in Figure 4-16 on page 74. IBM Tivoli zSecure Alert is further described in “IBM Tivoli zSecure Alert” on page 77.
Chapter 4. Focusing on the z/OS Security Server (RACF) 73
Tivoli Tivoli Security Operations zSecure Suite Manager Insight (TSOM zAlert is a real time mechanism that monitors events on zOS zSecure and matches the events against •Admin Other alerts a pre-set security policy •Visual From other •CICS tools devices/platforms TSOM •Audit •Alert •Command Verifier
Insight
From other devices/platforms TCIM applications Data collected and normalized Resource RACF into 7 w’s Manager •Who S •What A F Tivoli •On what Compliance Insight •When where Manager •Where from (TCIM) •To where z/OS
Provides the compliance dashboard
Figure 4-16 IBM Tivoli Security Operations Manager and Tivoli Compliance Insight Manager
Figure 4-17 on page 75 is an example of a z/OS security alert reported by Tivoli Security Operations Manager. This particular alert is pointing out that a userID that is not assigned the system OPERATIONS authority somehow managed to use that authority, which allows access to any data sets on the mainframe (this information surfaces from the analysis of the z/OS RACF-generated SMF records).
74 Designing for Solution-Based Security on z/OS
Figure 4-17 BM Tivoli Security Operations Manager display
Tivoli Compliance Insight Manager Tivoli Compliance Insight Manager is also part of the security information and event management (SIEM) system together with Tivoli Security Operations Manager, but it focuses on compliance functions related to people and system and data access. It ships with a number of compliance checking modules pertaining to regulations such as HIPAA and SOX.
Tivoli Security Operations Manager is focused on real-time correlation and operations management, while Tivoli Compliance Insight Manager is focused more on compliance and audit. In fact, Tivoli Security Operations Manager can also provide data to be fed into Tivoli Compliance Insight Manager.
The Tivoli Compliance Insight Manager z/OS Actuator (the z/OS Agent for Insight) runs on z/OS using z/OS components such as started tasks and data sets. The Tivoli Compliance Insight Manager uses the event data that is provided in the SMF records of type: 0, 2, 3, 4, 5, 6, 8, 10, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 28, 30, 31, 32, 33, 34, 35, 36, 27, 39, 40, 41, 42, 43, 45, 47, 48, 49, 50, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79 80, 81 (RACF) 82 (ICSF – Integrated Cryptographic Services Facility) 83 (Security Events) 84, 85, 88, 91, 92, 94, 96, 99, 100, 101, 103, 108, 109, 115, 116, 118, 119, 120
It copies this data to a file that is stored in z/OS UNIX Services and then passes the data to the Tivoli Compliance Insight Manager. It can capture and process z/OS (including z/OS
Chapter 4. Focusing on the z/OS Security Server (RACF) 75 UNIX), RACF, ACF2, TopSecret, and DB2 SMF data. It can also process zSecure Alert events, as shown in Figure 4-16.
Figure 4-18 shows the entry pane for the Compliance Dashboard that Tivoli Compliance Insight Manager displays. The dashboard shows all activities in the enterprise. The size of each circle indicates the amount of activity (logged events). On the axes the administrator can compare People (Who) with Information (on What).
The policy violations over time are shown on the right and log databases sorted to the needs of the user’s business (by department, regulation, or technology) are available.
Figure 4-18 IBM Tivoli Compliance Insight Manager Compliance Dashboard,Tivoli zSecure audit products
The second half of the zSecure product suite is related to audit and compliance functions, zSecure Audit, zSecure Alert, and zSecure Command Verifier. These three products run on z/OS and operate on the z/OS security data and commands.
IBM Tivoli zSecure Audit The zSecure Audit product runs in z/OS and analyzes security data, such as historical SMF data, and security configurations, such as RACF objects and system libraries, to identify and report on any security exposures.
Highlights of zSecure Audit functions are:
Live analysis of critical information that goes beyond z/OS and RACF analysis Customize reports to meet specific needs with flexible report and alert language Analyze SMF log files to create a comprehensive audit trail Analyze RACF profiles to get fast answers Detect system changes and integrity breaches to minimize security risks
76 Designing for Solution-Based Security on z/OS Track and monitor baseline changes for the RACF database Integrated remediation with Tivoli zSecure Admin Seamless links to enterprise audit and compliance
Figure 4-19 shows an ISPF panel displayed by zSecure Audit.
Figure 4-19 IBM Tivoli zSecure Audit.
Note that zSecure Audit also explains what the exposure is in words.
IBM Tivoli zSecure Alert The zSecure Alert product gathers events from SMF and provides real-time monitoring of intruders, system activity, from a security perspective, and system configuration. As with zSecure Audit, this product runs in z/OS.
The highlights of the provided functions are: Threat knowledge base with parameters from your active configurations Broad range of monitoring capabilities, including monitoring sensitive data for misuse on: –z/OS –IBM RACF – z/OS UNIX subsystems Easily send critical alerts to enterprise audit, compliance. and monitoring solutions Integrated remediation with Tivoli zSecure Admin
Chapter 4. Focusing on the z/OS Security Server (RACF) 77 Both zSecure Alert and zSecure Audit can send data to Tivoli Compliance Insight Manager for analysis and reporting. There are also other destinations for report and alert data.
IBM zSecure Command Verifier This product, previously known as zLock in the Consul portfolio, is often listed as an audit or policy compliance tool. However, it can be a very effective delegated and/or distributed administration control mechanism. It allows profiles to be defined to limit the RACF command arguments that can be specified, including filters on values.
For example, the system administrator may decide that no user can be created with a name of TESTUSER and set up RACF accordingly (zSecure Command Verifier uses the $CAR class of profiles). A delegated administrator attempting to create a user with this name will see the command being refused, as shown in Figure 4-20.
This product runs completely within a z/OS system. Because it uses an exit, it captures all administrative commands, whether they are issued through a command line, a job, or an administrative tool.
Figure 4-20 IBM Tivoli zSecure Command Verifier
78 Designing for Solution-Based Security on z/OS
5
Chapter 5. A brief reminder about System z integrated hardware cryptography
The systems z9 and z10™ implement enhanced functions of the cryptographic facilities already available in the z990 and z890 systems, that is, the Crypto Express 2 (CEX2C) feature and the CP Assist For Cryptographic Functions (CPACF).
© Copyright IBM Corp. 2008. All rights reserved. 79 5.1 Cryptographic function support in System z10
System z10™ includes both standard cryptographic hardware and optional cryptographic features for flexibility and growth capability.
The System z secure coprocessors (Crypto Express2 Coprocessors) implement all the protection mechanisms that are required by the FIPS 140-2 standard, and have been certified at the highest possible level of FIPS 140-2 level 4. Information about the FIPS 140-2 certification can be found at: http://csrc.nist.gov/cryptval/140-2.htm
The System z10 cryptographic functions include the full range of cryptographic operations needed for e-business, e-commerce, and financial institution applications. In addition, custom cryptographic functions can be added to the set of functions that the System z10 offers.
5.2 Overview of the cryptographic devices in System z9 and z10
Two types of cryptographic hardware devices are available in System z10. The cryptographic hardware facilities are usable only when explicitly enabled through the installation of Feature Code 3863, except for the CPACF SHA functions, which are always enabled regardless of whether the feature code is installed or not.
5.2.1 CP Assist for Cryptographic Functions (CPACF) Each System CP (central processor) has access to an imbedded assist processor in support of cryptography. CP Assist for Cryptographic Functions (CPACF) is conceptually considered part of the System Processing Unit (PU) hardware and as such is not really a coprocessor or an accelerator. Strictly speaking, it is just a set of instructions implemented in the PU, that is, the so-called Message Security Assist (MSA) instructions. The MSA instructions are described in z/Architecture Principles of Operation, SA22-7832.
CPACF offers a set of symmetric cryptographic functions that enhance the encryption and decryption performance of clear-key operations for SSL, VPN, and data storing applications that do not require FIPS 140-2 level 4 security. The MSA instructions provide for DES, T-DES, AES data encryption and decryption, MAC message authentication, and SHA-1 and SHA-2 hashing. These functions are directly available to application programs, because they are provided as problem state z/Architecture® instructions, reducing programming overhead. Alternatively, these functions can also be called in z/OS through the Integrated Cryptographic Service Facility (ICSF) component by an ICSF-aware application.
5.2.2 The Crypto Express 2 Coprocessor (CEX2C) The optional Crypto Express 2 Coprocessor (CEX2C) comes as a Peripheral Component Interconnect eXtended (PCI-X) pluggable feature that provides a high performance and secure cryptographic environment.
CEX2C implements the Master Key concept, which allows applications to use secure keys, that is, keys protected from compromise by being themselves encrypted with a Master Key that resides inside the coprocessor hardware enclosure.
CEX2C consolidates the functions previously offered on the z900 by the Cryptographic Coprocessor feature (CCF), the PCI Cryptographic Coprocessor (PCICC) and the PCI
80 Designing for Solution-Based Security on z/OS Cryptographic Accelerator (PCICA) feature. The CCF, PCICC and PCICA features are not available on System z9 and z10.
The CEX2C feature performs the following functions: Data encryption/decryption algorithms using secure keys (that is, keys encrypted with the symmetric Master Key or Key-Encrypting-Key) – Data Encryption Standard (DES) – Double length-key DES – Triple length- key DES DES, Double and Triple-DES key generation and distribution PIN generation, verification, and translation functions, using secure keys Pseudo Random Number (PRN) Generator Public Key Algorithm (PKA) Facility, using secure or clear keys These functions are intended for application programs that exploit public key algorithms, including: – Importing RSA public-private key pairs in clear and encrypted forms – Rivest-Shamir-Adleman (RSA) The following operations are executed with RSA keys of up to 4096 bits: • Key pair generation • Signature Generation and Verification • Import and export of DES keys under an RSA key, as needed, for instance, for the SSL/TLS handshake – Derived Unique Key Per Transaction (DUKPT) This service is provided to write applications that implement the DUKPT algorithms as defined by the ANSI X9.24 standard. DUKPT provides additional security for point-of-sale transactions that are standard in the retail industry. DUKPT algorithms are supported on the CEX2C feature for triple-DES with double-length keys. – Europay Mastercard VISA (EMV) 2000 standard Applications may be written to comply with the EMV 2000 standard for financial transactions between heterogeneous hardware and software. Support for EMV 2000 applies only to the CEX2C feature of System z9 or z10.
Other functions of CEX2C serve to enhance the security of public/private key encryption processing: Retained key support (RSA private keys generated and kept stored within the secure hardware boundary) - Currently not recommended to be used on System z. Support for the IBM 4753 Network Security Processor migration. User-Defined Extensions (UDX) User-Defined Extensions to the Common Cryptographic Architecture (CCA) functions support custom algorithms that execute in the CEX2C coprocessor. The UDX customized algorithm is added as a specific coprocessor firmware code built by IBM or by an approved third party. Building a UDX is an IBM service offering performed under contract.
Chapter 5. A brief reminder about System z integrated hardware cryptography 81 5.2.3 Crypto Express 2 Accelerator (CEX2A) mode CEX2A is actually a CEX2C that has been reconfigured by the user to only provide a subset of the CEX2C functions at enhanced speed. This reconfiguration is a manual process that can be performed only in System z9 or z10 and requires to manually switch the coprocessor operating mode at the system’s Support Element or HMC. The accelerator mode is intended to increase the throughput of hardware-assisted SSL/TLS handshakes. The reconfiguration is done at the coprocessor level, that is, a CEX2C feature can host a CEX2C coprocessor and a CEX2A accelerator, or two CEX2C coprocessors or two CEX2A accelerators. The reconfiguration works both ways, that is, from CEX2C to CEX2A and CEX2A to CEX2C. Master keys in the CEX2C domains can be optionally preserved when reconfiguring from CEX2C to CEX2A. The reconfiguration process is disruptive to the involved coprocessor/accelerator ongoing operations. The coprocessor/accelerator must first be deactivated at all ICSF instances, that is, all logical partitions that use it, before engaging the manual reconfiguration process. The FIPS 140-2 certification is not relevant to CEX2A because it is operating with clear keys only. The UDX, if any, is not available when operating in accelerator mode.
The only functions that remain available when reconfigured into a CEX2A are the former PCICA functions. These functions are used for the acceleration of modular arithmetic operations, that is, the RSA cryptographic operations typically used in the SSL/TLS handshake: PKA Decrypt (CSNDPKD), with PKCS-1.2 formatting PKA Encrypt (CSNDPKE), with ZERO-PAD formatting Digital Signature Verify
The Encrypt and Decrypt RSA functions support key lengths of 512 to 4096 bits, in the Modulus Exponent (ME) and Chinese Remainder Theorem (CRT) formats.
The maximum number of SSL transactions per second that can be supported on a System z9 or z10 by any combination of CPACF and CEX2A coprocessors is limited by the amount of cycles available to perform the software portion of the SSL/TLS transactions. When both PCI-X coprocessors on a Crypto Express2 feature are configured as accelerators in System z9, the Crypto Express2 feature is designed to perform up to 6000 SSL handshakes per second and per feature. This represents, approximately, a 3X performance improvement compared to z990 when using either a PCI Cryptographic Accelerator (PCICA) feature, or the performance achieved with a CEX2C feature in coprocessor mode.
Important: These figures are measuring a throughput, that is, it is necessary to initiate several threads of parallel requests to the CEX2A to achieve this level of performance.
In System z9 or z10, there can be a maximum of eight CEX2C features, and all coprocessors in these eight features can be reconfigured as Crypto Express 2 Accelerator (CEX2A).
82 Designing for Solution-Based Security on z/OS 5.3 Reminder on hardware coprocessors and logical
partitioning
Refer to System z9 Processor Resource/Systems Manager Planning Guide, SB10-7041, or System z10 Processor Resource/Systems Manager Planning Guide, SB10-7153 for further details about the setup of logical partitions for accessing the cryptographic coprocessors.
Each CEX2C coprocessor is hosting 16 “domains.” Each domain can be thought of as a set of hardware registers dedicated to an active logical partition. The domain a logical partition can have access to is specified in the partition’s image profiles. A domain is intended to securely hold the Master Keys that have been set via the cryptographic support software running in the logical partition (that is, ICSF for z/OS). When using the CEX2C coprocessor in accelerator mode, the domain refers to a specific queue that the coprocessor dedicates for requests arriving from this logical partition.
The user also specifies in the logical partition’s image profile which coprocessor (or “Adjunct Processor”, AP, in system hardware configuration terminology) the partition has access to. The real entity the logical partition has access to is therefore specified by the combination
Important: The combination
Note that the coprocessors a logical partition has access to are specified in two lists in the partition’s image profile: The on-line list - Where the specified coprocessors are made available to the logical partition as soon as it has been activated. The candidate-list - Which specifies which coprocessors the partition can have access to. However, these coprocessors must previously be varied manually on-line to the logical partition. The candidate line can specify coprocessors that are not yet physically installed in the system.
Note: The CPACF facility is implicitly shared, as any logical partition dispatched on a PU will systematically get access to this PU’s CPACF.
5.4 Reminder about z/OS hardware cryptography infrastructure
The CP Assist for Cryptographic Function (CPACF), Crypto Express 2 Coprocessor (CEX2C) and Crypto Express 2 Accelerator (CEX2A) have specific software requirements. The Integrated Cryptographic Service Facility (ICSF) is the support program for the cryptographic features: CPACF (alternatively to the direct use of machine instructions), CEX2C, and CEX2A. ICSF is integrated into z/OS and provides the API that z/OS-hosted software components can use to exploit the System z hardware cryptography.
Chapter 5. A brief reminder about System z integrated hardware cryptography 83 5.4.1 Reminder about ICSF
This section describes the overall hardware and software layout of the hardware cryptography implementation in System z9 and z10 with z/OS.
Figure 5-1 illustrates the overall infrastructure.
IMS DB2 z/OS Encryption Facility RSA Bsafe
RACF Middlewares/Applications VTAM VPN Kerberos Applications that use the Applications that use CICS TS PKI CDSA API The PKCS#11 API … Services PKCS11 … WebSphere JAVA
http LDAP TN3270 PKCS 11 OCSF z/OS FTP IBM SDK
CPACF System SSL direct call from applications Key datasets Secure keys ICSF CKDS Clear keys PKDS PKCS11 tokens RACF TKDS TSO/E
Hardware Master Key CPACF CEX2C domain Optional TKE Workstation
Figure 5-1 Overall hardware and software layout
The exploiters of the cryptographic services call the ICSF API. Some functions will be performed by the ICSF software without invoking the cryptographic coprocessor; other functions will result in ICSF executing routines containing the crypto instructions that drive the CEX2C (these instructions are IBM proprietary and are not disclosed). The crypto instructions that are used to interface with the CPACF are publicly disclosed in z/Architecture Principles of Operation, SA22-7832. These instructions are executed by a CPU engine and, if not addressing the CPACF functions, result in a work request being queued for a cryptographic coprocessor. The cryptographic coprocessor is provided with the following: – The data to encrypt or decrypt, from the application’s storage. – The key used to encrypt or decrypt provided by ICSF, as per the exploiter’s request. Note that these keys are represented as sealed envelopes here, to stress the fact that
these encryption/decryption keys are themselves encrypted and therefore unusable even in case of compromised key storage area. – These keys can be stored in ICSF-managed VSAM data sets and pointed to by the application using the label they are stored under. The Cryptographic Key Data Set (CKDS) is used to store the symmetric keys in their encrypted form, and the Public Key Data Set (PKDS) is used to store the asymmetric keys. The application also has the
84 Designing for Solution-Based Security on z/OS capability of managing its own key repository, on file or in storage and in encrypted or clear form. – The Token Key Data Set (TKDS) is an optional data set available at z/OS V1R9 and above, which is used by ICSF only for storing z/OS PKCS#11 tokens.
Note: Although performing some cryptographic services by software only, the ICSF started task (and therefore its cryptographic API) is not going to start if there is no hardware cryptographic facility available in the system, that is, at least one CPACF in operational status.
In Figure 5-1 on page 84 there are three APIs provided by z/OS to applications or middleware, besides the direct access that an application can have to the CPACF hardware using the MSA instructions: The ICSF APIs - These are the lowest level cryptographic APIs that z/OS provides. They are: – The IBM Common Cryptographic Architecture (CCA) API – A subset of the RSA PKCS#11 API, which is a new API introduced in z/OS V1R9 and provided in the C/C++ libraries.
Note: The ICSF PKCS#11 API implementation relies on already existing ICSF functions, with the consequence that ICSF and hardware cryptographic activities induced by the PKCS#11 API are actually the execution of CCA services and are reported as such from the utilization standpoint.
The System SSL API - This API is at a higher level than the ICSF API. System SSL transparently converts the cryptographic services requests it receives from applications into ICSF CCA service calls, or direct invocation of the CPACF, in direct support of the SSL/TLS protocol. System SSL is intended to provide applications with an SSL/TLS runtime support. Note that System SSL does not rely exclusively on the System z hardware cryptographic devices to provide the requested services, because it also has a software implementation of these services should, for any reason, hardware cryptography be unavailable on the system. The OCSF API - This is another high-level API, which is the z/OS implementation of the Intel Common Data Security Architecture (CDSA) set of cryptographic services. The exploiting application or middleware has to select the cryptographic service provider it wants to “attach” to. One of these service providers is actually ICSF, invoked via the CCA API. The IBM SDK also provides access. For Java exploiters to the ICSF CCA API, this implies, however, that Java cryptographic service providers have been properly specified. Note that in order to cover the range of cryptographic services that the Java Cryptographic Extension (JCE) provides, some Java cryptographic services are still provided by software even with the Java hardware cryptography provider selected.
Chapter 5. A brief reminder about System z integrated hardware cryptography 85 5.4.2 ICSF releases
As of the writing of this book, the ICSF release delivered with z/OS V1R9 is FMID HCR7740. A newer ICSF release (FMID HCR7750) has been made available, as an SMP/E installable Web deliverable (Cryptographic Support for z/OS V1R7-V1R9 and z/OS.e V1R7-V1R8), at: http://www.ibm.com/eserver/zseries/zos/downloads
5.5 Hardware cryptography exploitation on z/VSE
The main use of hardware cryptography on z/VSE stemmed originally from the need to provide hardware assistance to the SSL/TLS protocol. To meet this objective, specific cryptographic services were developed to be used internally in z/VSE. A decision was later made to externalize these services as the set of APIs shown in Figure 5-2 on page 87. Note that, because of the initial intent of providing cryptographic support specifically for SSL/TLS, the z/VSE cryptographic APIs are hosted by the z/VSE TCP/IP stack component. The z/VSE TCP/IP stack provides the cryptographic services and transparently invokes hardware cryptography when relevant and available.
Hardware cryptography using the CEX2C/CEX2A and CPACF devices is supported starting with TCP/IP for VSE 1.5D running on z/VSE 3.1.
5.5.1 RSA acceleration
Note that z/VSE exploits the CEX2C or CEX2A for RSA acceleration only, that is, using clear keys for: RSA decryption or encryption operations during initiation of the SSL/TLS session RSA signature of certificates built by the z/VSE certificate utility
5.5.2 CPACF exploitation
CPACF is used for SSL/TLS data transfer when one of the following symmetric algorithms has been agreed upon between the client and server: DES, Triple DES, or AES-128.
CPACF is also used when the SHA-1 algorithm has been selected for data integrity checking, both during data transfer and when building a certificate via the certificate utility.
Note: Whether hardware cryptography is used or not is transparent to the z/VSE TCP/IP applications. Whenever hardware cryptography cannot be used, the software implementation of the cryptographic services in the TCP/IP stack is used.
The use of hardware cryptography can be disabled via a setting in the so-called $SOCKOPT Phase for the z/VSE TCP/IP stack.
5.5.3 Infrastructure
The lowest level hardware cryptography API provided in z/VSE is the CryptoVSE API, where applications or middleware can call specific cryptographic services that are eventually performed by CPACF or CEX2C (in coprocessor or accelerator mode) devices.
86 Designing for Solution-Based Security on z/OS The SSL for VSE API is a higher-level API, similar to the z/OS System SSL API, intended to provide SSL/TLS-enabled applications with runtime assistance to handle the SSL/TLS protocol. This API transparently invokes the CryptoVSE functions. The SSL Daemon (SSLD) is not an API per se but manages the SSL/TLS protocol on behalf of non SSL-enabled applications, much as z/OS AT-TLS (Application- Transparent TLS) does.
TCP/IP Non SSL-enabled SSLD application
TCP/IP SSL SSL-enabled For VSE SSL application For API VSE Application CryptoVSE with cryptography
VSE Crypto Device driver
Clear RSA key only CEX2C CPACF domain
Figure 5-2 z/VSE Hardware Cryptography infrastructure
5.6 Hardware cryptography exploitation in Linux for System z
The hardware cryptography infrastructure for Linux for System z is shown in Figure 5-3 on page 88.
There are globally three layers of APIs: At the lowest level, the z90crypt, or the more recently available zcrypt, device driver provide an API usually not exploited directly by applications but rather intended for intermediate software layers that in turn provide more sophisticated cryptographic functions to the next upper level of code. The libica Linux library is such an intermediate cryptographic function library that offers a wide range of cryptographic functions, some of them being transparently performed by the hardware cryptographic devices under control of the device driver.
Chapter 5. A brief reminder about System z integrated hardware cryptography 87 As it stands today, libica, in the majority of cases, is still not directly called by applications or middleware. which rather rely on a higher-level cryptographic API such as the PKCS#11 API, or its Java version: the IBMPKCS11Impl cryptographic API.
Java Application Application Middleware/ Application (e.g. API API OpenSSl engine) IBMPKCS11Impl PKCS#11
API
libica API z90crypt (device)
Crypto Express2 Coprocessor CPACF domain
Figure 5-3 Linux for System z hardware cryptography infrastructure
5.7 Setting up the hardware cryptography configuration of z/VM
In z/VM real cryptographic coprocessors are assigned to guest virtual machines by specifying the CRYPTO parameter in the VM guest machine directory with the DOMAIN and APDEDICATED or APVIRTUAL operands. Refer to z/VM CP Planning and Administration, SC24-6083, for further explanations about the use of these parameters. APDEDICATED This specifies the number of the APs (that is, the CEX2C coprocessors) the virtual machine may use for dedicated access. The DOMAIN operand also must be specified to indicate the coprocessor domain to access in the APs. The APs specified must be selected from the set of APs selected on the PCI Cryptographic Online List on the Crypto Image Profile Page for the z/VM logical partition. APs in the candidate list have to first be put in the online status as viewed by the logical partition that is going to use them. The DOMAINs specified must be part of the set of domains selected in the Usage Domain Index list in the Crypto Image Profile Page for the logical partition. APVIRTUAL This tells the z/VM Control Program that this virtual machine may share access with other virtual machines to the clear-key functions only of the CEX2C coprocessor. In that case z/VM will drive the requests to whatever coprocessor is available, and it is not necessary
88 Designing for Solution-Based Security on z/OS to specify the DOMAIN operand when specifying the APVIRT operand because z/VM will reject all requests for services that would involve the use of secure keys.
Figure 5-4 is an example of a VM guest machine setup, where the z/VM system logical partition has access to APs 5 and 6 in coprocessor mode and AP 2 in accelerator mode. The z/OS VM guest machine’s directory has been set up to specify a dedicated access to domain 1 of AP 5 and 6, and the Linux VM guest machines are sharing access to whatever accelerator is available to the z/VM system.
No setup is required to share the CPACF because the facility is available to whichever guest program is dispatched on the PU.
Guest Directory CRYPTO APVIRT
z/OS guest Linux guest Linux guest
Guest Directory Guest Directory CRYPTO DOMAIN 1 CRYPTO APVIRT APDED 5 6 ICSF libica libica
z90crypt z90crypt
Domain 2 Domain 2
Dedicated Shared queue CP queue LPAR CP
Image profile Usage domain 1,2 + APs 2,5,6 in online/candidate lists Domain Domain 16 domain queues 1 2
Crypto engines Crypto engines
Coprocessor 2 coprocessors 5 and 6
Figure 5-4 Hardware cryptographic coprocessor assignment to VM guest machines
Chapter 5. A brief reminder about System z integrated hardware cryptography 89
90 Designing for Solution-Based Security on z/OS
6
Chapter 6. Using the LDAP directory as a User Registry
It is quite a common practice today for distributed platforms to perform user identification and authentication against a user registry held in an LDAP directory. Applications or middleware executing on z/OS also offer the capability to use an LDAP user registry instead of the RACF database. This assumes that these applications and middleware manage to perform the identification and authentication by themselves because z/OS does not provide an authentication service for an LDAP-based authentication.
We explain in this chapter how an LDAP directory can be used as a user registry. We also address the case where the LDAP user registry is hosted by z/OS and what specific advantages this configuration can provide to users.
© Copyright IBM Corp. 2008. All rights reserved. 91 6.1 Review of LDAP
In this chapter, we briefly review the basic concepts of the LDAP operations. More detailed explanations can be found in LDAP-related documentation sources, such as Understanding LDAP, SG24-4986.
You can also find some preliminary information about the z/OS LDAP implementation in Chapter 3, “z/OS security services” on page 25 and Chapter 4, “Focusing on the z/OS Security Server (RACF)” on page 41.
6.1.1 The LDAP data organization
An LDAP directory entry holds a set of information related to an object. The information itself consists of values given to attributes. For instance, the name of a user is kept in the directory as: commonName=John Doe Where commonName is the attribute which, by universally adopted convention, designates a user identity kept in the directory, and John Doe is a specific value (that is, a specific user in the directory) given to the commonName attribute.
LDAP users will refer, explicitly or implicitly, to these LDAP attributes as the target for add, delete, modify, and search operations. It is therefore required to specify to the LDAP server what are the attributes, and the format of their associated values, that users intend to store in the directory. This is done using the schema files.
The schema files The LDAP schema files hold the information that is required by the LDAP server for proper management of the user data stored in the directory in the form of attributes and relevant values.
The schema files specify a two-level organization for the hosted information, as follows: The object class level The object class specifies the set of attributes relevant to a specific object. For instance, the object class “person” specifies that the following attribute types are mandatory in an LDAP entry that holds the information for a “person” object: – The commonName, abbreviated as cn, which designates a person’s full name – The surName (sn), which designates the family name of a person The “person” object class also specifies that the “person” object information can be optionally complemented with the following attributes: – userPassword – telephoneNumber –seeAlso –description The attribute type level Here the schema files specify the format characteristics of the values that can be given to each specific attribute. As an example, the commonName and surName attributes associated values are expected to be UTF-8 character strings, whereas the userPassword attribute is to be a binary value.
92 Designing for Solution-Based Security on z/OS Some attributes are termed “operational attributes.” They are not directly related to user information kept in the directory but are intended to be used by the LDAP server itself and affect its internal functions. Note that the LDAP schemas also contain other information such as comparison rules when searching for attribute values, or whether an attribute can only get one value or can be given multiple values (multi-valued attribute).
Standardization of object classes and attribute types Any LDAP directory implementer can design and build a schema that defines user-created object classes and attribute types. Because experience has shown over time that there were consistent needs among users for specific object classes and attribute types, these entities have been standardized by bodies such as the IETF. This is the case, for instance, for the person object class, and others, that we are discussing in this chapter.
The LDAP entry An LDAP entry is a set of information actually kept as a collection of attributes and their values. When creating an LDAP entry the user specifies which object classes the entry is to contain, thus defining a set of attributes whose values are stored in the entry.
Note that an entry can contain several object classes and therefore comprises all the attributes associated with each of the involved object classes. For instance, an LDAP entry designating an IT user today commonly contains the person object classes, but also other object classes such as inetOrgPerson and organizationalPerson.
The LDAP Directory Information Tree (DIT) The LDAP entries that contain the stored information can be considered as nodes in a hierarchical structure called the Directory Information Tree. Each entry can have 0 or n children entries. However, an entry can only have one parent. An example of a very simplified DIT is given in Figure 6-1.
dn: "c=us" dn: "c=fr"
oc=country oc=country c=us c=fr
dn: "o=IBM,c=us"
oc=organization oc=organization o=IBM o=ACME dn: "o=ACME,c=us"
oc=person cn=John Doe userPassword=xxxxx
dn: "cn=John Doe,o=IBM,c=us"
Figure 6-1 Example of LDAP DIT
Chapter 6. Using the LDAP directory as a User Registry 93 We show (see Figure 6-1 on page 93) five entries of the DIT, organized into three hierarchical levels. Two entries are located at the top level of the DIT and both contain a “country” object (object class c). One entry contains the country attribute with the value “us”, while the other entry contains the country attribute with the value “fr”.
We show two children for the c=us entry, which contain an organization object and the organization (o) attribute, and likewise we show one out of three children of the o=IBM entry.
The LDAP entry distinguished name Note that each entry in the DIT is designated by a unique distinguished name (DN), which is a set of attributes and values that are used by the LDAP server as keys to retrieve the entry. The entries that we are showing in Figure 6-1 on page 93 have the following DNs: c=us and c=fr o=IBM,c=us and o=ACME,c=us cn=John Doe,o=IBM,c=us
The distinguished name given to an entry is actually the parent entry’s distinguished name augmented with the entry’s relative distinguished name (RDN™). As an example, the entry with the DN o=IBM,c=us has an RDN o=IBM which complements the parent’s DN c=us.
Groups entries Some object classes, such as groupOfNames, have been defined for the purpose of specifying groups of entries. In such object classes one attribute, usually the cn attribute, specifies the name of the group and another attribute, usually the member attribute, specifies the individual entries that are members of the group (it is a multi-valued attribute that contains the DNs of the members).
Multiple DITs Usually a single LDAP server can manage several DITs that coexist in the data stores it controls. Each DIT is identified with the distinguished name of the top entry, also called the “suffix”, which must be unique among all the DITs managed by the LDAP server.
Loading or off-loading DIT entries - the LDIF files LDAP operations are available for LDAP clients to create or read DIT entries. However, users may elect to use utility programs that process LDAP Data Interchange Format (LDIF) files for mass processing of DIT entries, because it might be needed when populating an empty DIT.
LDIF is a standardized format for recording LDAP directory entries on a flat file, which can be used for backup purposes or to manually propagate DIT contents between LDAP directories.
6.1.2 Access control in LDAP
The LDAP information model supports access control at the entry or attribute level. It is implemented via Access Control Lists (ACLs) associated with an entry or a specific attribute in an entry. The ACL specifies the distinguished names of users or groups that are permitted to access the information, with the specific access mode (search, modify, and so on) these users or groups are allowed to use. The ACL model assumes that proper LDAP user authentication (see 6.1.3, “Using the LDAP directory” on page 95) has been achieved, or that the access is performed by an anonymous, that is non-authenticated, user.
Note that LDAP implementations allow to define an LDAP Administrator as a user who, once authenticated, is not subjected to any access control.
94 Designing for Solution-Based Security on z/OS 6.1.3 Using the LDAP directory
The LDAP protocol implements the following set of operations: User session identification and authentication
–bind – unbind – abandon Information retrieval –search –compare Information update –add – delete –modify – modifyDN
LDAP user authentication The LDAP user authentication occurs during the bind operation and can be achieved using the following different mechanisms.
Simple bind All LDAP implementations support the simple bind mechanism where the user specifies the distinguished name of an entry and the password value that this entry contains. The LDAP server retrieves the entry during the bind operation and verifies that the user-provided password matches the password kept in the entry. The simple bind is illustrated in Figure 6-2.
« bind LDAP dn: cn=John Doe, o=IBM,c=us Password=xxxxx» Server dn: "c=us"
oc=country c=us
dn: "o=IBM,c=us" Successful oc=organization oc=organization authentication o=ACME Verify o=IBM LDAP client Userpassword
oc=person cn=John Doe userPassword=xxxxx
Authenticated DNs cn=John Doe, dn: "cn=John Doe,o=IBM,c=us" o=IBM,c=us …. Groups list …. If needed for Access control
Figure 6-2 LDAP authenticated bind
Chapter 6. Using the LDAP directory as a User Registry 95 Note that the LDAP server returns to the user a successful bind response and keeps track of the authenticated distinguished names and group memberships, should they be needed for access control. Simple Authentication and Security Layer (SASL)
SASL is a framework for providing authentication and data security services via a structured interface between protocols and the SASL authentication mechanisms. Implementations of the LDAP protocol support SASL authentication mechanisms, such as the following: SASL external bind and client and server authentication - This actually refers to an authentication achieved externally to the LDAP protocol. The most common example is the SSL/TLS authentication as performed, at the transport level, using digital certificates. GSS API Kerberos bind - This is the insertion in the LDAP protocol of the exchange of Kerberos tickets. CRAM-MD5 and DIGEST-MD5 authentication - This is a simple challenge-response mechanism based on hash values replacing passwords. LDAP as a user registry
As mentioned, the LDAP directory DIT can comprise entries related to systems users that contain authentication data such as user passwords. The LDAP server can then use these entries to proceed with user authentication at bind time.
These entries can also contain other information associated with the user represented by the entry, such as digital certificates.
To illustrate the use of an LDAP directory as a user registry, one can consider the possibility of moving the contents of a UNIX server’s /etc/password, /etc/shadow, and /etc/group files to entries in an LDAP directory. The UNIX users can then be authenticated using a Pluggable Authentication Module (PAM) that uses the LDAP protocol and directory to verify the user password and get specific additional data, if any, pertaining to this user.
The DIT entries associated with a UNIX user must then contain the attributes of the object classes person, posixAccount and posixGroup. Among others, these object classes provide attributes such as the user’s uidNumber, homeDirectory and loginShell name.
The authentication process When authenticating users against an LDAP user registry, the authentication itself is achieved via an authenticated bind using the distinguished name of the user’s entry.
Finding the user entry As explained above, the user’s entry in the DIT is designated by its distinguished name, which might be information not known from the end-user or simply inconvenient, for complexity reasons, to use. Provided that the LDAP client on the user side has been programmed to do so, the end user can instead provide a simple, unique attribute value that will be searched for in the directory entries. Let us take as an example the DIT shown in Figure 6-2 on page 95: the user entry distinguished name is “c=John Doe, o=IBM, c=us”, which is the distinguished name to be used for the authenticated bind. However, it is probably more convenient for the user to use the common name “John Doe”, which is defined in the entry. The user’s LDAP client must then be programmed to support the following process: 1. The user provides the unique common name value and the related password as an identity. 2. The LDAP client performs an anonymous bind to the LDAP directory and requests, in our example, a search for “cn= John Doe” in the DIT.
96 Designing for Solution-Based Security on z/OS 3. The search succeeds and the LDAP server response contains the distinguished name of the entry where the search argument was found. 4. The LDAP client then requests an authenticated bind using the password already provided by the user and the distinguished name returned upon completion of the previous search operation. 5. The LDAP client reports the completion status of the authenticated bind operation to the user. 6. In case of successful authentication, the LDAP server proceeds with a user “group gathering”, that is, it automatically collects all the group names the user might be declared to be a member of and keeps this list of groups should it be needed later for access control.
Note that, for this process to work, the common name attribute in the entry must be protected by an ACL that allows it to be read by an anonymous (that is, non-authenticated) user.
From a practical standpoint, applications that support user authentication against an LDAP user registry can generally be set up to select which attribute to perform the initial identity search on. A very common search attribute, provided that the user entry contains the inetOrgPerson object class, is the uid, that is, the short name of the user.
Getting additional user information out of the registry Once the user has been authenticated, the application can also request for additional user information that the LDAP user entry may contain. This information is obtained via an ldapsearch operation. A typical case of a search for additional user information is when the application itself requires to know which groups the user is a member of.
Finding user group membership User groups in LDAP can be represented by the groupOfNames or groupOfUniqueNames objects. These object classes contain the member or uniqueMember attributes, the values of which are the distinguished names of entries belonging to the group. The object classes groupOfNames and groupOfUniqueNames also contain a common name attribute, the value of which is the name of the group.
6.2 Using the z/OS LDAP directory as a user registry
The z/OS LDAP directory can be exploited by systems or applications that use the LDAP user registry. The user entries are managed by the TDBM (in DB2 tables) or LDBM (in HFS files) backend, using the standard schemas provided in z/OS or designed by the installation.
The SDBM backend also offers the capability of authenticating a user against RACF USER profiles during the LDAP bind. However, its use is somewhat more limited because the schema used in that case is fixed by IBM and specific to the z/OS LDAP implementation.
Chapter 6. Using the LDAP directory as a User Registry 97 6.2.1 Supported SASL mechanisms
The z/OS LDAP server supports the following authentication mechanisms, in addition to the simple bind mechanism with distinguished name and password (with or without SSL/TLS transport security): External - This is the SSL/TLS client authentication with an X.509 V3 digital certificate. The subject’s distinguished name in the certificate is preserved as the LDAP user’s distinguished name. This mechanism cannot be used for a bind to the SDBM backend as of z/OS V1R9. Kerberos. CRAM-MD5 - This mechanism cannot be used for a bind to the SDBM backend. DIGEST-MD5 - This mechanism cannot be used for a bind to the SDBM backend.
6.2.2 TDBM- or LDBM-based user registry
A TDBM- or LDBM-based user registry works as any other LDAP directory, provided that proper schemas have been loaded. The z/OS LDAP server is shipped with two predefined schema files containing schema definitions which the user may want to use with the LDBM or TDBM “directories”. These files are schema.user.ldif and schema.IBM.ldif and are located in the /usr/lpp/ldap/etc directory. The schemas are installed using an ldapmodify operation and they contain widely used object classes, and related attributes, such as person and inetOrgPerson.
Other non-z/OS-provided schema can be installed as long as they are provided in LDIF format. This would be required, for instance, if the posixAccount or posixGroup object classes are needed because they are not provided in the z/OS-delivered schema files.
userPassword encryption The userPassword attribute value can be kept encrypted in the LDAP user entry for confidentiality purposes. During the authenticated bind the z/OS LDAP server encrypts the password provided by the user and compares the encrypted password with the userPassword attribute value kept in the user entry.
The following encryption algorithms are supported: Two-way encryption with the DES, triple-DES or AES 256 encryption, optionally exploiting the System z hardware cryptography. One-way encryption with the following algorithms: –crypt() –MD5 –SHA
z/OS LDAP TDBM or LDBM Native Authentication The z/OS LDAP server has the ability to authenticate to the Security Server through the TDBM or LDBM backends by specifying a Security Server password, that is, a password kept in a RACF USER profile, on a simple bind to the backend. Authorization information—the gathering of groups the user belongs to—is still performed by the LDAP server based on the distinguished name used for the bind operation. This is the z/OS LDAP Native Authentication facility.
In order to get Native Authentication working, the LDAP server must be properly set up and the user entry with the bind distinguished name should contain either the ibm-nativeId
98 Designing for Solution-Based Security on z/OS (brought by the ibm-nativeAuthentication object class) or the uid attribute to specify the Security Server userID that is associated with this entry. The userID and password are passed to the Security Server and the verification of the password is performed by the Security Server.
This mechanism is illustrated in Figure 6-3.
LDAP z/OS Client TDBM or LDBM « bind Root dn: cn=John Doe, o=IBM,c=us LDAP Password=xxxxx» Server dn: "c=us" oc=country c=us dn: "o=IBM,c=us" Successful oc=organization oc=organization o=IBM o=ACME authentication password
oc=person userID cn=Johhn Doe Ibm-nativeid=JDOE
Verify dn: "cn=john Doe,o=IBM,c=us" UserID + password
userIDs/passwords RACF
Figure 6-3 z/OS TDBM or LDBM Native Authentication
Notes on z/OS LDAP Native Authentication: 1. Installations can exploit the user password management capabilities offered by RACF for LDAP authentication with minor modifications to their DIT: – The ibm-nativeAuthentication object class has to be installed. – Or the uid attribute can be used to contain the RACF userID (the uid attribute is part of the inetOrgPerson object class). – In any case, the user LDAP entry must not contain a password. 2. This, however, requires administering both the LDAP DIT and the RACF USER profiles. 3. Native Authentication also allows users to change their RACF password via LDAP operations. z/OS LDAP user group objects The z/OS LDAP server supports the following object classes intended to be used for collections of users: In static group entries: – accessRole – accessGroup – ibm-staticGroup – groupOfNames – groupOfUniqueNames In dynamic group entries: – ibm-dynamicGroup – groupOfURLs
Chapter 6. Using the LDAP directory as a User Registry 99 Groups of nested groups in other groups: – ibm-nestedGroup
The z/OS LDAP server also supports the ibm-allMembers and ibm-allGroups operational attributes to determine all members of a specific group or the complete group membership of a specific user.
6.2.3 Using the z/OS SDBM backend for authentication
The SDBM—the backend that establishes a connection to RACF—can be exploited for the purpose of authenticating the LDAP user only. The authentication is performed as usual during the simple bind with a “RACF distinguished name” and a password, or an SASL Kerberos bind. Note that: This requires the LDAP client to be enabled to use IBM RACF specific objects, which might not be possible with clients designed to only use the industry standardized object classes and attributes. Optionally, after successfully authenticating to the LDAP server, a list is created of the groups that the authenticated RACF userID belongs to. Only groups in which the user ID’s membership is active (has not been revoked) are included in the list.
Important: An SDBM authentication is just providing user identity and authentication data verification. It does not create any security context in z/OS that could be used further for access control of z/OS protected resources.
6.2.4 z/OS LDAP auditing
Events resulting from z/OS LDAP server activity can be recorded in SMF records.
LDAP server-generated auditing data The z/OS LDAP server can be configured to generate SMF type-83 subtype 3 audit records. These audit records contain information provided on LDAP client operation requests. The following LDAP operations can be audited: add, bind, compare, connect, delete, disconnect, exop, modify, modifydn, search, and unbind.
The LDAP server can be configured to write audit records when the operation successfully completes, when the operation fails, or for either case.
The LDAP server uses the R_auditx callable service to write the record to SMF. The SMF type-83 log records containing LDAP events can then be unloaded by using the RACF SMF data Unload utility for further analysis by auditing tools.
RACF generated auditing data When authenticating with the SDBM backend, RACF always produces SMF type-80 auditing records for failed authentication.
6.2.5 z/OS LDAP user registry synchronization
LDAP user registry synchronization can be achieved in different ways. Note that in any case the synchronization is achieved using regular LDAP operations such as ldapsearch against the synchronization source directory and ldapmodify to the target directory synchronization:
100 Designing for Solution-Based Security on z/OS Using the LDAP replication mechanism This potentially works for synchronizing the z/OS TDBM or LDBM backend directories under the condition that they have been defined the same object classes and attributes as their replicating partner directories. Note that LDAP replication does not operate for the SDBM backend. By an authorized external LDAP participant Such as the IBM Tivoli Directory Integrator product, that would detect changes in one directory among the synchronized set and would propagate the changes to the other directories of the set. On z/OS, the GDBM backend directory can be used to provide change log data that can be continuously inspected by these external participants. We give an overview of how this can be achieved for changes into the RACF “directory” in 4.5.2, “LDAP Change Log for changes in RACF USER and GROUP profiles and users-to-groups connections” on page 61. The change log notification can also be activated for changes to the TDBM- or LDBM-managed data, and likewise an external authorized LDAP participant can exploit the GDBM backend data to detect occurrences of changes.
Chapter 6. Using the LDAP directory as a User Registry 101
102 Designing for Solution-Based Security on z/OS
7
Chapter 7. Additional considerations about identification, authentication, and authorization services
In this chapter we address additional considerations regarding the possible implementation of the identification and authentication services, the infrastructures they require, and how their functional relationship with the authorization service can be affected by these implementations.
© Copyright IBM Corp. 2008. All rights reserved. 103 7.1 Identification and authentication service considerations
The purpose of identification, as mentioned in “User identification and authentication” on page 6, is to establish the identity of the user of the system. The authentication process establishes with an acceptable level of trustworthiness that the claimed identity actually belongs to this very user. The user identity can then be used for auditing and for authorization purposes, the latter as an individual identity or as a member of a group.
7.1.1 User identity
The main requirement for a user identity is to be unique among the population of potential system users. However, the format and syntax of the user name are constrained by the implementation of the authentication and authorization services in the system being accessed: Taking as an example z/OS RACF, the authentication data—that is, the password, or password phrase, or PassTicket—is associated to the specific RACF userID which is, because it is specified by the RACF syntax, a single string of eight characters maximum. If identification and authentication are to be performed by an LDAP server, then the user identity is expressed as an X.500 distinguished name. Authorization rights are bound to a user identity (or the identity of a group the user belongs to), typically in an Access Control List (ACL) that specifies the protected resource and the list of identities of users, or groups, who have access privileges to this resource. The system’s authorization mechanism requires that the authenticated users’ names, or names of groups, be provided in a form that make them usable for comparison against the definitions in the ACL. The RACF implementation of ACL for a resource is actually the “access list” in the resource profile, and requires that the users or groups with the names that have been defined for their RACF USER or GROUP profiles be specified.
7.1.2 Interoperable identities
Despite the fact that every operating system has its own specific format and syntax for users’ identity and depends on this syntax for the implementation of access control mechanisms, there are today identity formats and syntaxes that have been standardized in an attempt to make them universally acceptable by applications, independent of the platform the application is running on.
A typical example of such interoperable identities are the X.500 distinguished names used in the X.509 digital certificates. The Kerberos principal name is another interoperable identity, carried inside the Kerberos tickets.
Authentication of interoperable identities The authentication of these interoperable identities cannot, by definition, rely on users’ authentication data that are kept in an operating system’s local user registry, because they are precisely intended to circumvent the heterogeneous nature of those local user registries.
The authentication is then performed by the application referring to a user registry external to the system, or the identity is conveyed to the application using a protocol-designed sequence of interactions that also performs proper authentication. SSL/TLS or Kerberos are such protocols.
104 Designing for Solution-Based Security on z/OS Authorization and identity mapping Operating systems today are not providing access control implementations that would work using these interoperable identities. The exploitation of the operating system’s built-in access control, by an application that receives such interoperable identity, therefore requires a mapping from the authenticated interoperable identity to a local user identity, the latter being expressed in a format and syntax that fits the implementation of the platform access control mechanism.
Such a mapping can be done by storing additional data pertaining to the local user identity in the system’s user registry. As an example, for systems using LDAP as a user registry, the user’s LDAP entry is designated with a distinguished name that can be an SSL/TLS digital certificate X.500 subject’s name, and the entry contains an attribute that represents the local user ID that maps to this distinguished name (the sname or uid attributes are commonly used for this purpose).
When it comes to mapping Kerberos names to local user IDs, an LDAP user registry can still be used. In that case the user entries are expected to contain an attribute the value of which is the unique Kerberos name of the user (for example, the krbprincipalname attribute) and another attribute, such as sname or uid, that contains the mapped-to local user ID. In that case the mapping operation begins by searching all the directory entries for a krbprincipalname attribute value that matches the authenticated Kerberos name.
Identity mapping and auditing It is expected from the identity mapping implementations that an auditing trail be kept of the initial end-user identity, in its initial form, along with the mapped-to local identity. Such an implementation can then be extended to allow a many-to-one mapping (for instance, many digital certificates mapping to the same local user ID) and still preserve individual accountability.
7.1.3 Identity mapping in z/OS
z/OS provides APIs for user authentication using a digital certificate with the SSL/TLS or the SPKM-3 protocols, or using a Kerberos ticket with the Kerberos V5 protocol.
There are also built-in identity mapping facilities that a z/OS application can use to map a digital certificate X.500 name, or a Kerberos name, to a local RACF user ID.
RACF identity mapping RACF offers applications that need to perform identity mapping the R_usermap callable service for mapping a digital certificate X.500 name, or a Kerberos principal name, to a local RACF user ID. The R_usermap callable service relies on mapping information held in profiles in the RACF database.
The callable service _initACEE also provides for the mapping of a digital certificate to a RACF user ID.
Both services indicate to the application whether the mapping request was successful or not via the callable service return and reason codes, and pass the mapped-to user ID to the application in case of success.
Digital certificate X.500 name mapping Two mechanisms are available for digital certificate mapping in RACF: The certificate that is passed by the application exactly matches a certificate in a DIGTCERT profile in the RACF data base. The APPLDATA held in the DIGTCERT profile
Chapter 7. Additional considerations about identification, authentication, and authorization services 105 contains the name of the USER profile this certificate is associated with, that is, the RACF userID it is mapped to. The subject’s and issuer’s distinguished names in the certificate passed by the application match criteria defined in DIGTNMAP profiles in the RACF database. The DIGTNMAP profiles constitute a set of filtering criteria for the subject’s and issuer’s distinguished name and indicate which RACF user ID the certificate maps to when criteria are met. Additional mapping conditions, such as the application or system ID, can be specified in profiles of the DIGTCRIT class.
Note that RACF always attempts to perform the digital certificate identity mapping using the first method. If not successful, it then tries the second method, called Certificate Name Filtering (CNF) if, and only if, DIGTNMAP profiles have been defined.
The filtering criteria specified in the DIGTNMAP profiles can be used for a one-to-one mapping of the certificate, meaning that a unique certificate is mapped to a unique RACF user ID, but they have actually been designed to be more efficient in a many-to-one mapping configuration. In this latter case the intent is to map certificates containing specific values in their subject and issuer distinguished names to the same generic RACF user ID.
Note: The DIGTCERT, DIGTRING, DIGTCRIT RACF profiles, along with the Certificate Name Filtering facility, are thoroughly documented in z/OS Security Server RACF Security Administrator’s Guide, SA22-7683.
Kerberos principal name mapping Once the application has managed to decrypt and parse the Kerberos ticket, using the z/OS Kerberos or GSS-API, it can request a mapping to a RACF user ID using the R_usermap callable service.
The R_usermap callable service uses the profiles defined in the KERBLINK class of profiles. The resource name has the format /.../
and the APPLDATA field of the profile contains the RACF user ID to map the Kerberos name to.
Notes: Although the RACF user profiles may contain a Kerberos principal name in the optional KERB segment, the mapping operation is always performed using the KERBLINK profiles. If a RACF user has a Kerberos principal name defined in the USER profile, RACF automatically creates the corresponding KERBLINK profile. The resource name of the KERBLINK profile can be limited to /.../
Accountability of the original identity The application can request RACF to preserve the X.500 names of the subject and issuer of a mapped certificate in the ACEE control block for auditing purposes. As of this writing, the initial Kerberos name is not kept in the audit trail.
Enterprise Identity Mapping (EIM) A z/OS application can use the z/OS EIM APIs (available for C/C++ or Java applications) to map a non-z/OS identity to a RACF user ID. EIM is further described, with examples, in z/OS 1.6 Security Services Update, SG24-6448.
106 Designing for Solution-Based Security on z/OS Note, however, that EIM requires an LDAP-based infrastructure to be set up, as opposed to the mapping services provided by RACF which do not require any additional component to the system. Note also that the synchronization of the EIM Domain Controller LDAP directory data is not insured by z/OS, and so a mismatch between EIM and RACF contents will go unnoticed until failure of the z/OS application when using the EIM-provided identity.
7.2 Trusted Third Party authentication
The Trusted Third Party authentication scheme was originally developed in distributed configurations where entities are connected to non-secure networks with potentially high risk of compromise of the identification and authentication data that flow over the networks. The approach was not to allow any authentication data to flow in clear (that is, not protected by encryption or other means) and to use a specific server, known to be very secure and well protected (hence the Trusted Third Party (TTP)), to proceed with identification and authentication of applications’ users. The TTP provides the clients of the servers in the network with unforgeable proofs of successful authentication, or “credentials”, that the server applications will accept. The Trusted Third Party authentication technologies are heavy exploiters of cryptography, and Kerberos tickets and digital certificates are typical examples of such unforgeable credentials.
7.2.1 The conceptual view
This implementation requires, besides implementing a reliable Trusted Third Party, that the credentials provided be standardized so that they can be accepted by the many hosts that provide services over the heterogeneous network and be verifiable for truthfulness and integrity.
This also assumes that the technologies in use implement the notion of trustworthiness of designated systems at the entities that receive the credentials.
Figure 7-1 on page 109 is an illustration of the principles of operation of the Trusted Third Party authentication, with additional considerations pertaining to how participating entities can manage adapting to different standards. 1. The user identifies and authenticates to the TTP using unique secret information the nature of which depends on the authentication technology used. It is expected from the TTP to verify the user’s identity and the secret information. In most implementations of the TTP concept today this secret information is not transferred over the network. The user just demonstrates the possession of this secret information. As an example, this secret is a cryptographic symmetric key derived from a password when using a Kerberos Key Distribution Center as a TTP, or an asymmetric secret private key when dealing with a public key infrastructure Certificate Authority. This also implies that the TTP has ways of assessing the truthfulness of the user’s identity, either with a user registry of its own, as is the case with the Kerberos KDC, or by some other approach, for example the humanly driven investigation that a Certificate Authority conducts to insure the trustfulness of a digital certificate request. 2. Once authenticated, the user is provided with a credential issued by the TTP. To make this credential unforgeable, it is built using cryptographic techniques involving a secret key that only the TTP should know. The user is then left with two items:
Chapter 7. Additional considerations about identification, authentication, and authorization services 107 – The initial personal secret that was used to authenticate to the TTP – The TTP credential, which is proof that the user has been successfully authenticated, using this personal secret. The credential also contains the user’s identity. Examples of such credentials are Kerberos tickets and digital certificates. 3. The user then uses both items to authenticate to the server application, which proceeds with the following two steps: – It verifies the integrity and origin of the credential as having actually been issued by the TTP, and therefore knows who the owner of the credential is. – It verifies that the connected user actually still owns the secret that was used for the TTP authentication. To explain this last point with concrete examples: • If the credential in question is a digital certificate, then the connected user has to demonstrate possession of the private key that corresponds to the public key in the certificate. This is taken care of in the SSL/TLS protocol when the user authenticates using a digital certificate. • In the case of the Kerberos ticket, the user demonstrates to the server application that it knows the secret session key in the Kerberos ticket provided by the Key Distribution Center. Note that in any case, as already mentioned above, there is no secret flowing in clear over the network.
At this stage we can state the following: The TTP is conceptually the only host that needs a user registry, because the server applications receive the user identity imbedded in the TTP credential. The user identity, as expressed by the TTP, should be in a standardized format and syntax that is acceptable by server applications, regardless of what platforms they are operating on. The server applications must be set up with a trust policy that indicates which TTPs deliver credentials that are receivable. That is, the server applications must not accept credentials of any TTP without distinction, while the systems security administrators must decide which TTPs they want to work with based on several criteria, including their assessment of the trustfulness of the TTP’s operations.
108 Designing for Solution-Based Security on z/OS
Trusted •A highly trusted and scalable system 1-provide •With a secure authentication scheme identity Third •Provides standardized identity credentials -proceed with (e.g. X.509 certificates, Kerberos tickets) authentication Party and request credential 2-get unforgeable delegation or identity Identification and assertation authentication credential
3-use credential Server A Server B
APIs to APIs to •Validate credential with trust in TTP •Validate credential with trust in TTP •Map to a local userID (1:1, many:1) •Map to a local userID (1:1, many:1) •Control access against the local ID •Control access against the local ID
Industry standards Platform-specific Platform-specific implementation implementation
Figure 7-1 Principles of operation of the Trusted Third Party authentication
In Figure 7-1 we also point out the transformations the user identity may have to go through: The TTP provides identity in a standardized form that all network entities will accept. When it comes to exploiting this identity for access control checking, we are back to the situation where every platform has been designed with a proprietary format for the identity to be submitted for access control, and where a mapping mechanism is necessary. Depending on the implementation, that can be a one-to-one mapping or a many-to-one mapping (refer to 7.1.3, “Identity mapping in z/OS” above for specific z/OS information).
We show a commonly used configuration where the user’s request flows through a chain of server platforms, presumably each one with a different operating system or application software. This translates into the requirement for “delegation”, that is, a way for Server A to securely propagate the authenticated user’s request to Server B on behalf of this initial user, that is, by presenting to Server B a credential that Server B can use to safely authenticate Server A but containing the initial end-user identity.
The capability of delegating depends on the technology used: The Kerberos protocol allows delegation whereas a digital certificate cannot do it (propagating a certificate does not provide for authentication, because the authentication process requires possession of the corresponding initial private key, which Server A does not have in this case).
7.3 The concept of asserted identity
As an alternative to credential propagation one can use the “asserted identity” approach. In
Figure 7-1 on page 109, asserted identity is used when Server B trusts Server A for sending a user identity that has been properly authenticated upstream.
Asserted identity is quite a popular technique that is used to circumvent many problems related to credential propagation. It implies, however, that servers receiving the propagated identity can authenticate the partner which sent the identity, so that they can establish whether the propagated identity comes from a trusted source. This authentication can be
Chapter 7. Additional considerations about identification, authentication, and authorization services 109 achieved, for example, by Server A providing its own user ID and password that can be verified by Server B. It can also be achieved by establishing a dedicated network connection (a real or virtual private network) between Server A and Server B.
7.4 z/OS and Trusted Third Parties
As mentioned, z/OS applications can exploit Trusted Third Party authentication with the SSL/TLS, Kerberos and SPKM-3 protocols. z/OS can also host the Trusted Third Party application itself. We now explain these two aspects of the TTP authentication implementation from the z/OS perspective.
7.4.1 Extending the z/OS Trust Domain with TTP authentication technologies
Intrinsically z/OS is a “security island” in that the trust domain is constrained to the z/OS images that have access to the RACF database. The support of protocols such as SSL/TLS and Kerberos expands the trust domain in that non-RACF-provided credentials are deemed acceptable by z/OS applications.
A schematic view of this expansion is given in Figure 7-2 on page 111, where z/OS-hosted applications have connectivity to a TTP and RACF has been set up with a Trust Policy stating which TTPs can be trusted. There are two types of TTP that are supported as of z/OS V1R9 by the z/OS security services (and the authentication APIs made available to applications): A PKIX Certificate Authority that delivers X.509 V3 certificates and X.509 V2 Certificate Revocation Lists. z/OS provides APIs for digital certificate contents and certification path verification: – The Open Cryptographic Service Facility (OCSF) – The System SSL Certificate Management Services – GSS-API, with the SPKM-3/LIPKEY mechanism A Kerberos Key Distribution Center that delivers Kerberos V5 tickets. – z/OS provides the GSS-API and Kerberos V5 API.
The Trust Policy that is necessary to assess the trust in a TTP is implemented in RACF as: RACF certificate key rings, owned by applications, with proper Certificate Authority certificates connected to the key ring by the RACF administrator. RACF profiles in the REALM class of profiles to define the Kerberos KDC that can be trusted.
110 Designing for Solution-Based Security on z/OS
Trust Policy in RACF TRAFFIC Transaction DENIAL INTRUSION MONITORING OF TCP/IP Security SERVICE Security Business Processes
Platform Security z/OS Trusted hardware and operating system Third security RACF Party
Thez/OS «Securityisland» IMPERSONATION MESSAGE •RACF identification/authentication MODIFICATION The z/OS Extended Trust Domain •userID •RACF hosts the Trust Policy •Password/password-phrase •RACF maps userID to •Passticket •Certificate’s subject •RACF access control •Kerberos principal •Discretionary •MLS •Tivoli zSecure
Figure 7-2 Expanding the Domain of Trust with a Trusted Third Party
7.4.2 z/OS as a Trusted Third Party
z/OS comes with imbedded Trusted Third Party services with the Network Authentication Service component, which implements a Kerberos KDC in z/OS, and the z/OS PKI services which provide Certificate Authority functions from z/OS.
The z/OS Network Authentication Service The z/OS Network Authentication Service is a base component of z/OS and implements a Kerberos V5 server with a Key Distribution Center (KDC).
Refer to z/OS Integrated Security Services Network Authentication Service Administration, SC24-5926, for details about the setup, management, and use of the z/OS Network Authentication Service component.
The Kerberos protocol Kerberos is a distributed authentication service and protocol developed by the Massachusetts Institute of Technology (MIT), initially known as project Athena. An implementation is freely available from MIT, and is today at Version 5 with the specifications provided in RFC 1510.
In a Kerberos implementation a Trusted Third Party, the Kerberos Key Distribution Center (KDC), provides credentials (Kerberos tickets) to be used by KDC-authenticated clients for authenticating themselves to servers in the network. The Kerberos protocol aims primarily at the authentication; the integrity and the secrecy of exchanged data are optional. A KDC covers a Kerberos Realm, which is the set of network applications that are to trust its tickets. The trust can be extended to other KDCs, and users can then use inter-realm tickets.
The Kerberos protocol uses symmetric encryption (for example triple-DES or AES) and although the user’s Kerberos secret key is derived from the password, no passwords are flowing over the network.
Kerberos is today supported in many operating systems such as Windows 2000 and XP, AIX, UNIX, Linux, i5/OS®, and z/OS.
Chapter 7. Additional considerations about identification, authentication, and authorization services 111 Kerberos principles of operation Figure 7-3 is a simplified overview of the interactions with the Kerberos protocol, which all happen over TCP/IP. The Kerberos KDC hosts a user registry where all the user’s Kerberos secret keys are kept. The KDC also hosts an Authentication Server (AS) and a Ticket Granting Server (TGS).
Client Log Me In Kerberos Key Distribution Center login I recognize you, here is an Authentication Authentication Login Ticket Server to client workstation Client Application Authorize Me to Server B Ticket Granting Server Service Ticket for server B
Kerberos KDC Service Ticket to server B Security Realm Server A Server B Server C
Figure 7-3 The Kerberos protocol interactions
A very simplified explanation of the sequence of events goes as follows: 1. A user logs in to a Kerberos-enabled client. The client system sends an authentication request to the KDC Authentication Server. The client system also uses the user’s password to derive a Kerberos key that will be used to decrypt the KDC response. 2. The Authentication Server retrieves the KDC copy of the user’s Kerberos secret key (on the basis of the identity received from the client system) and the AS provides to the client an authentication ticket with a copy of a dynamically generated session key that the client will have to re-use for further requests to the KDC. This session key copy is encrypted with the client’s secret key, and therefore only the legitimate client should be able to re-use this session key. 3. When the client application needs to reach a service on the network, it asks the TGS for a service ticket for a particular server (Server B in Figure 7-3) and provides proof that it could retrieve the value of the session key that the KDC sent to it in the authentication ticket. 4. The KDC now dynamically generates a session key to be shared between the client and Server B. It actually provides two copies of this session key: one copy encrypted with the client Kerberos secret key, another copy encrypted with Server B’s secret key (of which a copy is kept by KDC). Note that other information is sent encrypted with Server B’s secret key, such as the now authenticated identity of the client, a time stamp, and the ticket’s lifetime. 5. When the client is ready to send a request to Server B, it sends a Kerberos service request message that contains the data encrypted with Server B’s key that the KDC provided. It also sends its own identity in the message, encrypted with the session key found in the service ticket that it has been able to decrypt. In this service request message Server B can retrieve the value of the session key, because it was delivered encrypted with its own Kerberos secret key, and uses the session
112 Designing for Solution-Based Security on z/OS key to decrypt the rest of the information sent by the client in the message. If everything performs correctly, the client is identified and authenticated to Server B.
More information can be found in Putting the Latest “z/OS Security Features to Work, SG24-6540.
The z/OS Kerberos implementation The z/OS KDC implementation is shown in Figure 7-4. The Key server function is performed by the SKRBKDC z/OS UNIX application that receives requests for Kerberos tickets, generates the tickets and provides them to the requesting client. SKRBKDC binds to the z/OS TCP/IP stack and provides authentication server (AS) and Ticket Granting services (TGS).
The Kerberos user registry can be the RACF database or a Kerberos registry implemented in UNIX files.
When the RACF database is used as the Kerberos user registry, the REALM profiles are used to define the name of the local Kerberos realm and the names of other realms that can be trusted. The REALM profile also contains the ticket generation policy for the local realm.
The KERB segment in the USER profiles contains the Kerberos data peculiar to the user (Kerberos name, Kerberos key, and so on) and the KERBLINK profiles are used to map a Kerberos name to a local RACF userID.
z/OS
y RACF profile classes RACF ƒ REALM ƒ KERBLINK y KERB segment in user profile
Kerberos Kerberos Registry Key Distribution Center (KDC)
Kerberos clients SAF
R_kerbinfo (AS) y Authenticates Users R_ticketserv y Grants TGTs Authentication Server
R_usermap (TGS) Ticket y Generates Session Keys Granting y Grants service tickets based on TGT Server SKRBKDC
kerberos ticket from client enabled application
Figure 7-4 The z/OS Network Authentication Service
We also show, in Figure 7-4, a z/OS Kerberos-enabled application, Note, however, that z/OS can provide the KDC functions without hosting Kerberos-enabled applications itself.
The z/OS Network Authentication Services exploit the System z hardware cryptography when available.
Chapter 7. Additional considerations about identification, authentication, and authorization services 113 The z/OS KDC can also share a trust association with other KDCs, that is, link the z/OS Kerberos realms with other realms for mutual recognition of their Kerberos authentication tickets. This is depicted in Figure 7-5, where the z/OS KDC is shown first as the only KDC authenticating and providing tickets to Kerberos clients such as Windows XP workstations. The clients can use these tickets to authenticate to Kerberos-enabled servers running in z/OS
or in other systems in the Kerberos realm. Figure 7-5 also shows the case where two Kerberos realms are sharing a trust relationship. The first realm is established with the Microsoft Active Directory® KDC and the second one with the z/OS KDC. The two KDCs share a secret key that is used in the generation and validation of Kerberos tickets, so that Windows XP clients are authenticated by the Microsoft Active Directory but still get tickets that give them access to services in the z/OS realm.
z/OS Kerberos RACF enabled KDC service
z/OS - RACF KDC
Kerberos inter-realm enabled key service
Windows Active Windows XP Directory
inter-realm key
Windows XP
Figure 7-5 Single realm and realms with shared trust
Should the user want to exploit Kerberos authentication, and the optional integrity and secrecy of messages, the following z/OS components are Kerberos-enabled: DB2 V7 and above (for authentication) FTP client and server (for authentication, optionally data integrity and privacy) Telnet server (for authentication, optionally for data integrity and privacy) LDAP client and server (for authentication) rshd server (for authentication, optionally for data integrity and privacy) NFS server (for authentication, data integrity and privacy) Miscellaneous practical information on Kerberos implementation Here is some information that might prove to be useful when considering implementing a TTP authentication with Kerberos: As mentioned already, users' secret Kerberos keys are derived from users’ passwords. The user issues the password at the Kerberos-enabled client but there is no password
114 Designing for Solution-Based Security on z/OS transfer over the network, there is only transfer of Kerberos messages encrypted with secret keys. There is a Kerberos-protected service available for users to remotely change their Kerberos key, actually via a password change, in the KDC. If RACF is the KDC user registry, then this service changes the RACF user password as well. The Generalized Security Services API (GSS-API) is a very popular API for kerberizing applications. It is available in z/OS. Interoperability considerations – Despite the many options available in the Kerberos messages and tickets, the well known basic ones usually interoperate. – The reference implementation is the MIT Kerberos V5, as described in RFC 1510 plus the different on-going revisions. – The using entities should all support the algorithms that are used for: • The session key generation in the KDC • The encryption of the authentication and service tickets • The data integrity checksum – The contents of the tickets Some fields, like the authorization data field, have their contents left to the applications. It is therefore mandatory that client and server applications be compatible regarding the contents of these fields. – The Kerberos administration tools for client and KDC administration Although looking alike in different implementations, these tools are not standardized. – Kerberos local APIs Different APIs might not interoperate, such as a GSS-API and the Kerberos API, and it is therefore strongly recommended that client and server use the same API. – Exploitation of the Kerberos message information by Kerberos-enabled services. Experience shows that server applications can be designed so that, for instance: • Some services may ignore the authenticator message. • Some services do not provide mutual authentication. Scalability considerations These are important considerations because the demand on management and infrastructure resources increases as the Kerberos network grows. Things to consider: – The network infrastructure should properly support real-time communication between clients and the KDC. – The KDC should prove large and scalable enough to hold a copy of all the Kerberos secret keys in use by all the entities in the realm. – Because the Kerberos tickets are stamped with their validity start date and time and have a lifetime fixed by the KDC, it is necessary that all entities in the realm have their time synchronized. The time skew acceptable by default is 5 minutes. Authentication delegation
The Kerberos protocol supports delegation of the initial requestor by intermediate servers. The tickets that intermediate servers receive from upstream entities should have been marked “forwardable” by the KDC. These intermediate servers then request the KDC for their own delegated ticket to be presented to the next downstream server. Miscellaneous additional Security considerations – The authentication process is exposed to network denial of service attacks that would prevent access to the Authentication and Ticket Granting servers.
Chapter 7. Additional considerations about identification, authentication, and authorization services 115 – The ticket lifetime is adjustable in the KDC and must be considered as a good means of mitigating miscellaneous exposures. Usually tickets have a life time of 8 hours. – The Kerberos key can be subject to password guessing attack. Almost all Kerberos implementations today use the ““pre-authentication” feature of Kerberos, where when the client requests an authentication ticket, it also provides data encrypted with its Kerberos key in the request. Pre-authentication is implemented by default in the z/OS Authentication Server. If RACF is the KDC user registry, presenting wrongly encrypted Kerberos authentication requests to the z/OS AS results in getting the user revoked, using the same criteria as set in RACF for wrong password presentation.
Important: Because of its design, Kerberos is well adapted to be used in networks of a moderately sized population, with the KDC properly protected against denial of service attacks. Increasing the user population in realms may lead to oversized and unmanageable KDC user registries.
The recommendation is therefore to consider implementing Kerberos at the intranet level rather than in the Internet.
z/OS PKI Services z/OS PKI Services is a base component of z/OS that implements PKIX Certificate Authority functions. A Certificate Authority (CA) operates at the core of a so-called Public Key Infrastructure (PKI).
All details about the implementation, setup, and use of the z/OS PKI Services can be found in z/OS Cryptographic Services PKI Services Guide and Reference, SA22-7693.
The Public Key Infrastructure (PKI) A PKI is the set of software and storage products, networking facilities, and administration services that support the use of digital certificates. The role of the Certificate Authority is to provide certificate users with services to obtain, renew, or revoke certificates and publish information on revoked certificates.
A conceptual view of a PKI is given in Figure 7-6. The trust model, shown in the left upper corner, works as follows: 1. The user generates an asymmetric key pair and keeps and protects the only instance of the private key. 2. The public key is sent to a Certificate Authority, along with additional information that includes the key owner identity, to the CA. 3. The CA should ensure the veracity of the requestor’s identity information and then build a file to become the digital certificate to be owned by the entity whose identity has been provided. The certificate, among other things, contains the public key and the owner’s identity that have been sent. The certificate is digitally signed by the CA and is made available to the requestor and, in general, to whoever needs it.
Note: It must be understood that an X.509 V3 certificate is by no means secret data. It is on the contrary intended to be freely available. Its integrity is verifiable at any time
using the CA’s digital signature.
4. When the certificate’s owning entity deals with a server that accepts certificates as means of authentication, it sends its certificate to the server application. The server application has been set up to trust certain CAs and has access to their certificates (that is, their identity and public key, among other things). The server application can then proceed with
116 Designing for Solution-Based Security on z/OS the verification of the signature of the client certificate to assess its integrity. A successful verification results in trusting the client identity in the certificate as being valid and being the owner of the public key in the certificate. 5. To achieve the authentication, the server application should verify, using encrypted data, that the client also owns the private key that corresponds to the public key in the certificate. The SSL/TLS protocol, for instance, uses exchanges of encrypted dynamically random numbers to verify that the authenticating client is indeed the owner of the private key as well.
The Certification Authority: the Trusted Third Party
Mary's Verifies Public CA's Key Signature CA Digital Identification Digital Signature certificates of trustworthy CAs
"Mary"
Mary's Digital Certificate
Mary's Privat Authentication e Key
Check ownership of Mary's private key Certification Certificate Revocation Lists Authority Issuance
Certificates and 2-Certificate Issuance CRLs 1-Certificate Request Repository
The Public Key Infrastructure (PKI) as 4-Certificate Revocation Checking described in the IETF Cerificate Certificate, PKIX standards Owning exploiting Entity Entity
3-Certificate Utilization
Figure 7-6 The Public Key Infrastructure and its trust model
The PKI itself is composed of several elements, shown in Figure 7-6. Note that we abide by the description of a PKI as provided in the IETF PKIX standards. Note also that the PKIX standards specify the use of the X.509 V3 digital certificate and the X.509 V2 Certificate Revocation List (CRL). The Certificate Owning Entity, which we simply call the “client” in our examples. This is the network entity which is to obtain the certificate from the CA and is to use it, for instance, as authentication purpose against a Certificate Exploiting Entity kind of application. The CA is also to deliver information on certificates which have been revoked. A certificate is getting a revoked status on a decision made by the certificate’s owner or by the CA.
Chapter 7. Additional considerations about identification, authentication, and authorization services 117
Note: Do not mistake certificate expiration with certificate revocation. Certificates have a fixed validity period and become expired at the end of this period. This is a normal
situation in a certificate life cycle, and the certificate owner can request for a certificate renewal.
A certificate revocation is an emergency measure to prevent the use of an otherwise valid certificate. In such a case, for instance when the certificate owner’s private key has been compromised and the certificate could then be used for impersonation.
An application that accepts certificates as means of authentication should also consult the revocation information made available by the CA before accepting the certificate. A common way for the CAs to provide this information is to issue a so-called Certificate Revocation List (CRL).
Note that the consultation of a CRL is usually controlled by an option in the certificate-exploiting applications, and requires a specific setup to be properly performed in these applications.
Because it might be acceptable not to consult a CRL in small CA domains with a limited amount of users, all part of the same organization, it is, on the contrary, strongly recommended to have this facility enabled for larger populations of users with cross-organization CA domains.
Implementation of z/OS PKI Services z/OS PKI Services is a base component of z/OS intended to provide CA services hosted by z/OS to users on z/OS or other platforms. It is up to an installation to decide whether to set it up and make it available to the installation, or extra-installation, users. It is necessary to additionally start two instances of the z/OS HTTP server (also a base component of z/OS).
A high-level representation of the z/OS PKI Services implementation is given in Figure 7-7.
1 z/OS HTTP Server •User requests and receives X.509 V3 certificate via browser interface 5 2 •Client can get a certificate via SCEP (Simple Certificate Enrolment 3 Protocol)
SCEP 7 client OCSP requestor 6 6
•Certificate Revocation List published in LDAP directory 4 and HTTP files •Support for OCSP (Online 3 Certificate Status Protocol)
Figure 7-7 z/OS PKI Services
118 Designing for Solution-Based Security on z/OS The interactions between users and z/OS PKI Services are as follows: 1 Users request the X.509 V3 digital certificates via the HTTP/HTTPS protocol. Users can also download the z/OS PKI Services CA certificate from the z/OS Web site, so that they can install this certificate as being trusted in their applications.
2 z/OS PKI Services comes with a set of HTML pages and CGI modules that constitute its “templates”. The templates are used for communication with the requestors and to initiate the certificate build process for the request. The templates are customizable by the installation.
As of the writing of this book, the templates delivered in z/OS interface with the user to satisfy, by default, requests for the following certificate types: One-year PKI SSL browser certificate This certificate is for end-user client authentication using the SSL/TLS protocol. The validity period is one year. One-year PKI S/MIME browser certificate This certificate is for browser-based e-mail encryption. Two-year PKI browser certificate for authenticating to z/OS This certificate is for end-user client authorization using SSL/TLS when logging onto a z/OS application. It contains a hostIDMap attribute the value of which is a RACF user ID to map the certificate to. It therefore implies that this userID has a USER profile defined in RACF, and the mapping to this userID is under tight control by the RACF administrator via profiles in the DIGTCERT and SERVAUTH classes (refer to z/OS Cryptographic Services PKI Services Guide and Reference, SA22-7693, for details about the administration of RACF userID mapping via the hostIdMap attribute). Two-year PKI Authenticode® - code signing server certificate This certificate is to be used by applications that verify signing of software modules. Two-year PKI Windows logon certificate For end-user client authentication for an Active Directory user logging in to a Windows desktop using a smart card. Five-year PKI SSL server certificate This certificate is to be used by SSL/TLS-enabled servers for their authentication to SSL/TLS clients. Five-year PKI IPSEC server (firewall) certificate For firewall server identification and key exchange. Five-year PKI intermediate CA server certificate For subordinate (non-self-signed) certificate-authority certification. n-year PKI browser certificate for extension demonstration To get a demonstration certificate to show all extensions supported by PKI Services. One-year SAF browser certificate For end-user client authentication and RACF, not z/OS PKI Services, is the certificate provider. It also implies that the entity that owns the certificate also has a USER profile with password defined in RACF. One-year SAF server certificate For SSL/TLS server authentication and RACF, not z/OS PKI Services, is the certificate provider. It also implies that the entity that owns the certificate also has a USER profile with password defined in RACF.
Chapter 7. Additional considerations about identification, authentication, and authorization services 119
Note: As mentioned, these are all X.509 V3 certificates. What makes them different here are the contents of the so-called “extension fields” in these certificates, which are
specific to the exploiting applications.
3 The request for certificates is stored in a VSAM data set, waiting for the administrator’s approval before starting the build and signature process. The administrator interfaces with z/OS PKI Services also using the HTTP/HTTPS protocol.
Some certificate types can be tagged as “auto approval” in the templates, in which case the build and signing process is started immediately.
4 When approved, the build and signature processes are performed. The certificate is signed by the z/OS CA’s private key. The key pair, and certificate, owned by z/OS PKI Services are kept in a RACF key ring. Note that a proper audit trail of the z/OS PKI Services activities is kept in SMF type 80 records.
Notes: Exit points are provided in z/OS PKI Services that give control to user-provided exits prior to and after request processing. z/OS PKI Services support signing certificates with the RSA or DSA algorithm. RSA signatures can be assisted by System z hardware coprocessors.
5 When available, the certificate is downloaded via HTTP/HTTPS by the requestor and is also made available to an LDAP directory (which could be a z/OS or non-z/OS based directory) owned by z/OS PKI Services.
6 z/OS PKI Services also periodically issues a Certificate Revocation List for those certificates it has put in the revoked status. The CRL comes in two forms: as entries in the z/OS PKI Services-owned LDAP directory, or as z/OS UNIX files that can be downloaded by HTTPS/HTTPS.
z/OS PKI Services also supports the Online Certificate Status Protocol (OCSP - also carried by HTTP/HTTPS) where OCSP-enabled applications can get a real-time status of a specific certificate, as recorded into z/OS PKI Services. This has to be compared to the CRL, whose period of issuance could be of several days (this is adjustable in z/OS PKI Services), with the consequence that the revocation status of a certificate is not published immediately but has to wait for the next scheduled update of the CRL.
7 z/OS PKI Services also support, beginning with z/OS V1R8, the Simple Certificate Enrolment Protocol (SCEP) where devices, already registered by PKI administrators, can automatically obtain certificates from z/OS PKI Services via HTTP/HTTPS communications. SCEP has been developed mainly for those network devices that authenticate using digital certificates. IPSec VPN key servers are such devices.
Miscellaneous practical considerations on PKI implementation The IETF PKIX standards must be abided by today when implementing a PKI, and are expected to provide proper interoperability between the PKI entities. Scalability considerations – A user usually requests a certificate once a year, that is, needs to connect to the CA once a year. However, applications that use the OCSP protocol can induce a heavy workload on the network.
120 Designing for Solution-Based Security on z/OS – With asymmetric encryption, the secret to manage is the private key, which remains strictly the owner's responsibility. The certificate owners are responsible for their private key storage and management. Likewise, the CA is responsible for keeping and protecting its private key. – The entities in a PKI are usually not subject to tight time synchronization. At least the UTC day is required to be synchronized. – Certificate exploiters must have the Certification Authority's public key. Therefore, means of providing the CA certificate must be in place whatever the size of the user population is. Authentication delegation – PKI does not support delegation, because a genuine authentication can only be performed with the initial end user that possesses the only instance of the private key. A possibility is to implement identity assertion with downstream servers once the certificate has been authenticated. Security considerations – Because authentication is based on proof of possession of the private key, it is of prime importance for users to properly protect this key. It is usually done via password or biometrics protected files or devices. Extra protection is obtained when the device is of the smart card type that holds the private key. It is then transportable by the user and will perform, once plugged into a computer, the required cryptographic computations without revealing the secret key value to the host computer.
Important: It is of paramount importance to protect the CA’s private key because compromise of this key would result instantaneously in getting all the certificates already signed by this CA (and there might be millions of such) potentially invalid: users would not have any means of distinguishing legitimate certificates from newly forged ones.
When the RSA signature is used by the z/OS PKI services, the CA’s private key can be kept in the ICSF PKDS data set.
The publication of a CRL via LDAP or HTTP exploits commonly used infrastructures and protocols. However, the drawback of using CRLs is their periodic updates, which potentially introduces delay in making a revoked status visible. OCSP provides a better solution from this standpoint but is not as commonly supported as the LDAP protocol can be.
Chapter 7. Additional considerations about identification, authentication, and authorization services 121
122 Designing for Solution-Based Security on z/OS
8
Chapter 8. Overview of TCP/IP network security
This chapter describes the security implications that are involved when you connect a system to a non-secure TCP/IP network. It introduces the z/OS built-in functions that protect the hosted applications communications and z/OS itself from non-secure networks threats.
The assumption is that the basic security considerations regarding the operating system and applications have already been carefully taken into account, because establishing network-level security is of limited effectiveness if the basic platform security itself is questionable.
Consult the following references when designing and setting up z/OS network security: z/OS Communications Server IP Configuration Guide, SC31-8775 z/OS Communications Server IP Configuration Reference, SC31-8776 z/OS Communications Server IP System Administrator’s Commands, SC31-8781
© Copyright IBM Corp. 2008. All rights reserved. 123 8.1 General discussion - non-secure network threats
Much has already been written about the threats that users are exposed to when connecting to the Internet. All these threats are carried by the same, and only possible vector: the IP datagram. This is why it is so important to be able to apply the ISO 7498-2 principles to each datagram conveyed by non-secure networks.
The threats can be categorized based on the levels at which they occur: At the TCP/IP stack level The TCP/IP host itself, whether the header part or the data payload, can be harmed by the contents of the IP datagram. This may become possible because of a design issue in the stack code, which does not handle certain options or bit configurations in the IP datagram correctly. These vulnerabilities are therefore vendor-dependent and even code-level dependent, and information about the existence of these weaknesses is usually widely published over the Internet. Therefore, it is strongly recommended, for all platforms, to always apply the latest service updates to the TCP/IP stack code. At the communication level Common threats can be grouped into two categories: intrusion, and Denial of Service (DoS) attacks. – Intrusion threats, generally speaking, consist of the capability to acquire undue privileges in the system in which the TCP/IP stack is running, because of weaknesses in the stack code itself, usually complemented by weaknesses in the platform security products. Intrusion is generally the first step in causing more damage to user data or to the operations of the system itself. – In Denial of Service attacks, the attacker manages to prevent the receiving TCP/IP stack from providing the expected services. A DoS attack can be instigated in the system itself as the consequence of an intrusion, but can also be initiated from the network. DoS attacks initiated from the network fall into two general types: •The single packet DoS, where the IP datagram carries lethal contents to the receiving TCIP/IP stack This is the typical consequence of a design or coding mistake in the TCP/IP stack code, which ends up crashing the stack when processing the datagram. •The multiple packet DoS, where an attacker manages to flood the receiving TCP/IP stack with illegitimate communications, thereby preventing the overloaded stack from providing the expected services to legitimate clients Multiple packet attacks can be conducted by generating a very high volume of faked client requests, or by exploiting open weaknesses in the TCP/IP protocol itself. Not much can be done to protect against these attacks at the TCP/IP stack itself; minimally, the stack and the operating system should be designed not to overly consume system resources during the overload period. The problem is rendered even more challenging by the fact that it is often very difficult to detect at first whether a stack is under a DoS, or is just facing a peak of regular requests from clients. Installations usually take a holistic approach to preventing DoS attacks by installing software probes (intrusion detection probes) at several locations in their network, in which detected events are collected and correlated at a central point, to provide fast and overall accurate alerts. At the application level, where an IP datagram goes safely through the stack and the extracted data is a danger to the application
124 Designing for Solution-Based Security on z/OS Here again, you are dealing with design or coding mistakes, but at the application level. Again, to prevent this, perform proper application code maintenance and, if possible, up-front filtering of the received IP packets on the basis of authentication of the sender and integrity checking of the received data.
Note: A clear-cut classification of all Internet threats would be impossible because there are so many ways of conducting attacks and exploiting potential TCP/IP weaknesses.
Two final points complete our discussion on Internet threats: Users should not rely on a TCP/IP stack to provide, by itself, full protection against a hostile environment, even with very strong stack codes. There will always be a need for additional protection mechanisms such as firewalls or intrusion detection services; for example, administration errors might weaken the TCP/IP or system setup and the network holistic view that is often required to properly react to some types of attacks. It is worth mentioning again that, whatever security devices or products are put in place, the inherent security of the operating system (the platform-level security) is the first line of defense that all security mechanisms rely on.
8.2 Network protection and network security zone considerations
Network boundaries are created to isolate networking zones with differing security policies. These boundaries implement restrictions on the type of traffic that is allowed in a zone. An example might be to restrict inbound access to only HTTP traffic on port 80 and HTTPS traffic on port 443 to the network zone where the Web server resides. There are two network zones with different policies here: one zone does not have any restriction on the TCP/IP traffic, and the other zone only accepts inbound HTTP and HTTPS requests, and on the well-known ports.
Firewall devices are used to allow this traffic and block all others. In its simplest case, a firewall is a device that implements a policy regarding network traffic. It creates boundaries between two or more networks, and stands as a shield against unwanted penetrations. However, a firewall in itself is not meant to be the only line of defense in an hostile network, but rather a mechanism to slow down the progress of an intrusion and to collect data and issue warnings along this progression.
Network Address Translation One way of shielding information about the network that the firewall protects is by resetting the addresses in the packets so that outbound traffic appears to have originated from an address associated with the firewall itself, and cannot be used to discover the protected zone IP addresses. This resetting is called Network Address Translation (NAT) and its primary function is to hide the trusted network from untrusted networks.
The use of NAT provides very popular, pervasive, and simple network protection. However, be aware that NAT may interfere with other technologies such as the IPSec VPNs, as mentioned in 8.6.3, “Implementing network communication security with IPSec - IPSec modes” on page 140.
Chapter 8. Overview of TCP/IP network security 125 Firewall technologies Firewalls may be bundled with other features such as content filtering, Virtual Private Network (VPN) functionality, and even authentication. Some of the devices commonly in use to isolate network security zones are described in this section. Packet filter firewall Packet filter firewalls decide which traffic should be allowed between the two networks that they are connected to, and what should be blocked. They do this by analyzing individual network packets and matching them to a set of predefined rules. Packet filter firewalls can operate with static rules fixed by the network security administrator. Some of them can dynamically generate filtering rules to adapt to special, predefined, situations. Circuit level firewall Circuit level firewalls confirm that a packet is either a connection request or a data packet belonging to a connection. To validate the connection, the circuit level firewall examines each connection to ensure that it offers a legitimate handshake for the protocol being used. Data packets are not forwarded until the process is complete. Application layer firewall Application layer firewalls examine the information in network packets, but they operate at the application level. They view information as a coherent and meaningful data stream and not as a series of packets; therefore, they are able to scan information being passed over them and ensure that the information is acceptable based on their set of rules and logic. This allows these firewalls to make intelligent decisions about what to do with packets that pass through them. So-called “proxy” servers are, in fact, application layer firewalls. Dynamic packet filter firewall Also referred to as stateful inspection, dynamic packet filtering also exploits the contents of packets to determine the state of active connections and obtain a representation of the active communications sessions. This is taken into account when making decisions about which packets to let flow or to deny. This increases the scope of threats that can be countered, as compared to static filtering. Router Routers are interconnection devices that link discrete networks and forward packets between them. A router makes decisions about whether to forward a packet between networks based on a configuration table of routes, and address information, in a packet. A router may be used to isolate networks from one another, thus preventing traffic on one network from unnecessarily spilling over to another network.
8.2.1 Common network models - overview
An architectural approach for establishing proper network protection consists of classifying network security zones in terms of potential threats they are exposed to, and of determining the impact of related attacks on the proper operation and integrity of the organization.
Figure 8-1 illustrates how an organization can be broken into different network security zones on the basis of a tradeoff between what needs to be protected and the amount of protection the organization can afford to put in place.
126 Designing for Solution-Based Security on z/OS
Internet Internet Production Intrarnet DMZ Zone
Restricted
client
Management Zone
Uncontrolled Controlled Secured Controlled
Figure 8-1 An approach to network security zones classification
Note: The breaks between each network zone, as shown in the figure, indicate the use of a firewall that clearly delineates each perimeter from the next.
The resulting topology yields a classification of network security zones such as: Uncontrolled This classification refers to anything outside the control of an organization. Access from the uncontrolled environment to systems in the controlled zone could be via a wide number of channels. The Internet is the archetype of an uncontrolled network zone. Controlled This classification restricts access between uncontrolled and restricted. Services from this zone to the uncontrolled zone are exposed to attacks. These services are protected to the extent that protection does not hamper their intended communications with the uncontrolled zone. A second line of defense is installed between the controlled zone, traditionally designated as the demilitarized zone (DMZ), and other zones in the organization, if the services in the controlled zone are compromised. The intranet is considered to be a controlled zone because it can be compromised. Restricted This classification means that access is restricted and controlled. There is no direct communication with external sources located in an uncontrolled zone. Secured This classification means that access has to be given for operational reasons, but this is accomplished through highly trusted channels. External controlled This classification refers to a zone that is external to the organization, but with business needs for communications; it is typically a business partner organization. There is limited trust in this zone network protection because you cannot vouch for the complete safety of someone else’s organization.
Chapter 8. Overview of TCP/IP network security 127 8.2.2 Mapping network zones to an organization’s network components This section describes the following types of network zones and explains how they map to our organization network: Uncontrolled (the Internet) Controlled (an Internet-facing DMZ and the intranet) Restricted (a production network) Secure (a management network)
Internet (uncontrolled zone) The Internet is a global network (that is, a network of networks) that connects millions of computers. It cannot be controlled, and there should be no components of the organizational network in it.
It is also generally unsafe for components to communicate with each another across uncontrolled networks.
Internet DMZ (controlled zone) The Internet DMZ is generally a controlled zone that contains components with which clients may directly communicate. It provides a “buffer” between the uncontrolled Internet and internal networks. Because this DMZ is typically bounded by two firewalls, there is an opportunity to control traffic at multiple levels: Incoming traffic from the Internet to TCP/IP hosts in the DMZ Outgoing traffic from hosts in the DMZ to the Internet Incoming traffic from internal networks to hosts in the DMZ Outgoing traffic from hosts in the DMZ to internal networks
The transport between a controlled zone and an uncontrolled zone is classified as public. The transport between a controlled zone and another controlled or a restricted zone is classified as managed.
Typically, the DMZ is a possible location for GUI (or other means of presenting) servers that service external customers.
Production zone (restricted zone) One or more network zones may be designated as restricted; that is, they support functions to which access must be strictly controlled, and direct access from an uncontrolled network should not be permitted. As with an Internet DMZ, a restricted network is typically bounded by one or more firewalls and incoming and outgoing traffic may be filtered, as appropriate.
The transport between a restricted and a controlled zone is classified as managed. The transport between a restricted and a secured zone is classified as trusted.
The restricted zone is typically dedicated to production systems.
Intranet (controlled zone) Like the Internet DMZ, the corporate intranet is generally a controlled zone that contains components with which clients may directly communicate. It provides a “buffer” to the internal networks.
The specific level of trust in an internal network dictates the components which may be deployed within it.
128 Designing for Solution-Based Security on z/OS Management zone (secured zone) One or more network zones may be designated as a secured zone. Access is only available to mandatory systems management communications. Access into one area does not necessarily give access to another secured area.
The transport into a secured zone is classified as trusted.
It is quite common to dedicate special networks for the management zone so that management components are properly differentiated from production system components.
Other networks The network examples we use do not necessarily include all possible situations. There are organizations that extensively segment functions into various networks. However, in general, the principles discussed here can be translated easily into appropriate architectures for such environments.
Placement of various data components within network zones is both a reflection of the security requirements in play and a choice based on an existing or planned network infrastructure and levels of trust among the computing components within the organization. Requirement issues often may be complex, especially regarding the specific behavior of certain applications. With some knowledge about the organization’s network environment and its security policies, reasonable component placements are usually easy to identify.
8.2.3 Practical design
The DMZ, or outermost perimeter network, is the separation point between the set of entities under the organization’s control and everything that it does not control (for example, the Internet). In this area, information is exchanged with limited, calculated risk.
Creating a DMZ involves adding firewalls for extra layers of security. Firewalls are often used in multi-machine networks arrangements to protect the resources that live on that private network, such as critical data, business applications, and sensitive information. A wide variety of topographies can be appropriate for a DMZ; however, the basic units usually look something like the layout illustrated in Figure 8-2.
Chapter 8. Overview of TCP/IP network security 129
Internet Internet Production Zone DMZ
Reverse proxy App Server server
App Server Load balancer
client App Server
Non-critical Web server
Uncontrolled Controlled Restricted
Figure 8-2 Basic DMZ design
This design allows for the separation of the front-end presentation logic on the non-critical Web server, and the business logic on the application servers in the private network. The infrastructure allows secure transactions and processing in stages, thus reducing the demands on systems.
8.3 TCP/IP stack hardening
The term “hardening” describes what should be done, in terms of operating system and communications setup, on a system that is going to be connected to a non-secure network. Although some systems propose hardening tools (automated or semi-automated ways to achieve this kind of setup), hardening can be generally seen as a set of best practices intended to secure a TCP/IP host. This section explains what the hardening process means for the z/OS platform.
When selecting which services are to be provided by the hardened system, the objectives are: Keep the system at the bare minimum of required interactions with the network by strictly disabling all services that are not required. Typically, on z/OS and other platforms, this is achieved by controlling who can start and who can use these services, along with access control of TCP/IP resources such as ports and stacks, which are to be used to propose the services to the outside world. Pay particular attention to the services provided that are known, because of their design or reference implementation, to be possible vectors of attacks against the system itself or to other connected systems (for example, routing, DNS, FTP, and so on). Ancillary services that may establish TCP/IP connections (for example, Syslogd, ping, traceroute, and so on) during their normal operations should also be looked at. A reference implementation is an early implementation of a standard that often focuses on the functional aspect and leaves other, non-directly-relevant aspects (such as security)
130 Designing for Solution-Based Security on z/OS incompletely implemented. Experience shows that follow-on implementations by vendors are strongly inspired by the reference implementation, up to the point where its flaws can be duly reproduced and carried forward. In z/OS, this is expected to be taken care of by proper parameters in the services definitions. For instance, routing is disabled by default in the z/OS TCP/IP stack, and it requires you to specify DATAGRAMFWD in the IPCONFIG statement of TCPIP.PROFILE to enable it. (Other examples include the capability of protecting the FTP server from bounce attack; the use of the security features of the BIND 9 DNS; the capability of disconnecting the Syslogd daemon from the network; and so on.) Manage and exploit to a maximum the security features of the base operating system. In z/OS, that would particularly focus, for e-business applications, on UNIX System Services security: – Program library integrity with Program Control – Use of access control lists to secure UNIX resources – Control of daemon authority via RACF profiles –And so on Take into consideration other items, such as: – Minimize the number of user accounts that can be used to log on the system, and protect the accounts data. RACF is used on z/OS, and its NOPASSWORD user attribute (“protected user”) would help here. – Have auditing running and have audit logs protected with integrity checking, if possible. In z/OS, SMF auditing can be used. As an alternative, applications calling Syslogd can request that the logs be kept in HFS files.
Note: z/OS exploits RACF protection of the auditing data sets or files. It does not provide integrity checking of the auditing logs contents.
– The assumption is that the system has robust built-in TCP/IP security. This is the case for z/OS, where the TCP/IP stack is designed to withstand most of the known attacks. Although the z/OS stack resists these attacks, the z/OS Intrusion Detection Services feature can be used to trigger alarms and collect data when such an attack is received.
The next sections focus on which z/OS built-in facilities are available to protect the z/OS TCP/IP stack from intrusion and prevent unauthorized use of TCP/IP resources.
8.4 z/OS network protection
Prior to general availability, z/OS Communications Server went through a variety of testing. This testing included security-related threats, for example, test cases that reproduce common Internet threats. The attacks in these test cases were selected from a variety of sources including Computer Emergency Response Team (CERT); for more information about this topic, refer to:
http://www.cert.org These tests established that the z/OS TCP/IP stack can properly resist such attacks. In addition, the z/OS Communication Server team performs ongoing threat assessments and issues software updates when needed.
A set of protections are built into z/OS and z/OS Communications Server to enhance the security level of the z/OS connection to a non-secure network by preventing network-issued
Chapter 8. Overview of TCP/IP network security 131 attacks from affecting applications running in z/OS. These protections focus on detecting such attacks and alerting the system’s operations team if they occur. Built-in protections are also intended to prevent the z/OS instance from being an initiator or participant in an attack aimed at another system on the network.
Figure 8-3 offers a general view of the various security-oriented functions that are imbedded in the z/OS TCP/IP stack.
e.g. WebSphere Application Server
Intrusion detection services Application protect against attacks of RACF is used to prevent various types on the unauthorized user access to system's legitimate (open) TCP/IP resources (stack, port services ports, networks) z/OS TCP/IP Stack Scanning Hostile packets SAF protection Traffic flood
Application Transparent TLS AT-TLS provides SSL/TLS IPSec VPNs provide for TCP/IP protection Independently of the communications encryption and application Intrusion Detection Services authentication. All cryptographic operations are handled by the TCP/IP stack IP Filtering IP filtering blocks out all IP traffic that this systems doesn't specifically permit, per IPSec Source Destination Protocol, … Network adapter e.g. OSA-E
•All protections are optional network •Up to 8 TCP/IP stacks can run concurrently in a single z/OS instance
Figure 8-3 z/OS Communications Server security
There functions are discussed in more detail here: IP Filtering allows a network administrator to control the network traffic into or out of the z/OS by selectively denying access to specific IP packets based on corporate security policy. z/OS IP filtering is further discussed in 8.5, “IP Filtering” on page 135. IPSec provides authentication, integrity, and data privacy between any two TCP/IP stacks. It creates a virtual private networks (VPNs) enabling an enterprise to extend its local and private network across a public network, for the secure transfer of data. IPSec in z/OS exploits the hardware cryptographic capabilities of the System z. z/OS IPSec is further described in 8.6, “IPSec virtual private networks” on page 137. Application Transparent Transport layer Security (AT-TLS) performs the SSL or TLS protocol in the TCP layer of the stack transparently to the applications that use TCP/IP sockets. This reduces or eliminates application development overhead, maintenance, and parameter specification, because applications do not need to be designed to support SSL or TLS. Note that AT-TLS also provides an API that AT-TLS-aware applications can use to interact with the internal processes of the SSL/TLS protocol (refer to 8.7, “Application Transparent TLS” on page 144). Intrusion Detection Services (IDS) detects, records, and defends against TCP/IP ports scans, IP datagram-based attacks, flooding and denial of service attacks (see 8.9, “Intrusion detection and z/OS Intrusion Detection Services” on page 149).
132 Designing for Solution-Based Security on z/OS Protection of network resources is performed by RACF via the SAF interface on the z/OS platform. RACF protects network resources such as the TCP/IP stack, TCP/IP ports, network management commands and resources from unauthorized access. Note: IP filtering and IPSec support in the z/OS TCP/IP stack is referred to as “IP Security”, which is not a reference to the IPSec protocol.
8.4.1 TCP/IP-oriented additional RACF protections
Beyond protecting access to the z/OS and z/OS UNIX resources, RACF can also control access to system resources specifically engaged when using a network connection. This section provides an overview of the RACF protection of z/OS TCP/IP resources, and explains what resources can be protected by profiles in the SERVAUTH class. The resource manager that mediates access to these resources is the z/OS TCP/IP stack.
Network access The z/OS TCP/IP stack has an option to activate the SAF protection of a resource that identifies an IP network or IP address. In other words, RACF, or any other external security manager, can be used to control applications access to and from a specific IP address. The resource itself is defined by a statement within the TCP/IP profile data set. This statement defines a resource name and maps it to a specific IP address or network.
This is illustrated in Example 8-1, which shows the definition of two “security zones” in the TCPIP.PROFILE dataset.
Example 8-1 NETACCESS example NETACCESS INBOUND OUTBOUND 9.100.199.162 WORKSTN DEFAULT OTHERNW ENDNETACCESS
The two security zones are actually resources that have been defined via the NETACCESS statement in the TCPIP.PROFILE data set: WORKSTN represents IP address 9.100.199.162, while OTHERNW applies to all other IP addresses, also known as the “default zone”. In this example, the controlled resources include both inbound and outbound traffic of these zones.
If the RACF SERVAUTH class is active, and the resource profile for a security zone has been defined with UACC(NONE), then any user ID attempting access to a network defined within the NETACCESS statement must have been explicitly permitted READ access to the resource. For example, in order to communicate with 9.100.199.162 on a z/OS system with a system ID of MVSIV by using the TCP/IP stack started with the job name TCPIP2, the user ID would need permission to the following resource: EZB.NETACCESS.MVSIV.TCPIP2.WORKSTN
The resource name has a predefined syntax with the following qualifiers: EZB.NETACCESS are fixed qualifiers. The system ID where the protection is to operate (MVSIV, in this example). The TCP/IP stack started task where the protection is to operate (TCPIP2, in this example). The resource name that is defined in the NETACCESS statement in the PROFILE.TCPIP data set (WORKSTN, in this example).
Chapter 8. Overview of TCP/IP network security 133
Important: This protection enforces the access control for local applications to open an outbound TCP/IP connection or to receive from an inbound connection. It is not a
direct protection against external threats, such as IP filtering provides. Instead, it enforces local applications’ authority to use TCP/IP resources.
Typically, when this protection is set up, a Trojan horse kind of program (not authorized to the resource by the RACF administrator), would be prevented from communicating with the protected network entities.
Port access Similar to network access, port access implements access control for TCP/IP ports using a resource name of the following form:
EZB.PORTACCESS.MVSIV.TCPIP2.SERVER1
Again, the first two qualifiers are predefined.
Corresponding to this statement, the PORT reservation statements in the TCPIP.PROFILE data set would have to specify the resource name such as shown in Example 8-2.
Example 8-2 Port statement using SAF PORT 21 TCP * SAF SERVER1 23 TCP * SAF SERVER1
For any task to use TCP ports 21 or 23, permission to this resource profile would be required. The TCP/IP port SAF resource protection applies to UDP and TCP communications.
Tip: You can also consider using the following options. They do not use SAF protection of resources because they are fully implemented within the TCP/IP stack: You can control directly the use of ports numbered 1024 and lower via the TCPCONFIG RESTRICTLOWPORTS and UDPCONFIG RESTRICTLOWPORTS statements within the PROFILE.TCPIP data set dataset. In addition, the PORTRANGE and PORT statements can be used to restrict access of applications to ports. You can use the BIND option in the port statement as a security option, because the server will be listening only to a specific IP address and not to all IP addresses the stack is bound to. For ports that are intended not to be used, you can specify the RESERVED keyword in the PORT or PORTRANGE statement. This prevents applications running in the z/OS instance from using the port. An application attempting to bind to this port will fail the bind() function.
Stack access Continuing the pattern already established, the following syntax can be used when identifying a TCP/IP stack as a RACF-protected resource (up to eight TCP/IP stacks can execute concurrently in a single z/OS instance):
EZB.STACKACCESS.MVSIV.TCPIP2
With this resource defined to RACF with a UACC of NONE, all users who need access to any IP resource would need to be explicitly permitted in the resource access list.
134 Designing for Solution-Based Security on z/OS
Tip: You can implement a simple setup for network segregation in your z/OS image by starting several TCP/IP stacks (for a maximum of eight stacks concurrently running in a
single z/OS instance), with each one of these stacks being connected to a different network and protected with a different RACF resource name.
8.5 IP Filtering
IP Packet Filtering protects the network by blocking undesirable network traffic. A network administrator can deny or allow any given IP packet inbound or outbound to the z/OS system by defining IP filtering directives in a z/OS TCP/IP stack IP Security policy.
The traffic that is to be allowed or blocked can be identified based on the following information: The IP source or destination address in the IP Packet The protocol (TCP, TCP with ACK, UDP, ICMP), that the IP datagram is carrying The source or destination port The direction of flow of traffic, inbound or outbound to the system Whether the received IP packet is intended for the local TCP/IP host or it is to be routed to another host The current day, and time of day The network interface the traffic is flowing through
In z/OS, the information to identify the traffic pattern is specified in the IP Security policy. The policy is loaded into the TCP/IP stack by the Policy Agent (PAGENT) utility, where it is used to build an IP filter table that the stack consults for each IP packet that enters or leaves the system.
The IP filtering policy also specifies what action has to be taken when an IP packet matches one of the rules in the IP filter table. The action can be: Deny the packet. Permit the packet. Permit the packet with IPSec protection.
If the action is Permit the packet with IPSec protection, then the packet is subject to an additional process, as dictated by the IPSec authentication and encryption directives, before it is received or sent. IPSec is described in 8.6, “IPSec virtual private networks” on page 137.
Extensive logging facilities are also available to keep track of the TCP/IP stack operations regarding permission or denial of IP packets, along with collection of relevant network communication data.
The network administrator defines the IP filtering policy. The PAGENT is a z/OS component that loads a policy from the file it resides in into the networking layer of the TCP/IP stack, where the policy will be duly observed.
Figure 8-4 shows an IP Filtering setup for traffic intended to end at the z/OS instance (“local” traffic), where IP traffic with specific hosts (represented as workstations here) is forbidden both ways.
Chapter 8. Overview of TCP/IP network security 135
Applications IP Filtering Policy
Sockets Administrator
Transport protocol layer TCP and UDP
POLICY AGENT DENY IP Networking Layer
Network Interfaces PERMIT
IP network
Figure 8-4 IP Filtering for local traffic
In contrast, the IP Filtering setup illustrated in Figure 8-5 permits only IP traffic transiting via the z/OS TCP/IP stack (“routed” traffic).
Applications IP Filtering Policy Sockets Administrator
Transport protocol layer DENY TCP and UDP
POLICY AGENT IP Networking Layer
Network Interfaces PERMIT
IP network
Figure 8-5 IP Filtering for routed traffic
136 Designing for Solution-Based Security on z/OS Default policy The default policy, which is imbedded in the z/OS TCP/IP stack, does not need to be defined by a security administrator and can be activated by a system command. This default policy can be used to immediately block all traffic in case of a network attack.
8.6 IPSec virtual private networks
IPSec is a TCP/IP protocol standard adopted by the industry for traffic flowing in Virtual Private Networking (VPN). It has been specified by the IPSec working group of the Internet Engineering Task Force (IETF) and allows TCP/IP users to extend their communications across an untrusted network, such as the Internet, without compromising their communications security. IPSec datagrams indicate that they carry protocol number 50 or 51 data and can therefore be duly recognized by network hosts that are set up to process them or, on the contrary, to let them flow unprocessed.
IPSec provides for authentication, integrity, and data privacy of IP traffic between any two IP network hosts, using cryptographic techniques at the IP packet level. Hosts that support the IPSec protocols can exchange these IP packets and benefit from the security that encryption or authentication bring.
The IPSec process is implemented in the IP networking layer of the TCP/IP stack, and is therefore available to any network communication without requiring any modification to the application. It is transparent to the stack upper-layer protocols as well. In a sense, IPSec provides blanket protection for all IP applications and protocols by implementing security for communications flowing between two TCP/IP hosts.
Because running IPSec is optional in a TCP/IP stack, it can be used to protect a segment of a communication path, or to insure end-to-end security for the entire communication path. An IPsec endpoint can be the TCP/IP host that is the origin or destination of the traffic, or it can be an intermediate gateway TCP/IP host that cryptographically processes the IPSec traffic (that is, decrypts incoming traffic, or encrypts outward-bound traffic) before letting it flow.
Note: Both ends of an IPSec communications are implicitly authenticated. This implies that implementing IP filtering on the basis of the origin address for these communications is redundant with the protection that IPSec provides. In this sense, the use of IPSec may also lead to infrastructure simplification.
8.6.1 IPSec protocols and modes
As explained in this section, IP packets can be processed by IPSec according to two different protocols, depending on what level of protection is deemed necessary for the transported data.
Authentication Header protocol Authentication Header (AH) protocol provides for authentication and integrity of packets; that is, it ensures the truthfulness of their source IP address and insures that their contents have not been modified, using the following mechanisms: Data integrity Algorithms such as HMAC-MD5 or HMAC-SHA ares used to generate a cryptographic checksum to ensure data integrity.
Chapter 8. Overview of TCP/IP network security 137 Data origin authentication A secret key, shared by the two IPSec endpoints, is used to create the cryptographic checksum so that the data origin can also be verified. Replay protection
This is also provided by using a sequence number field with the specific AH header in the packet.
Packets processed according to the IPSec Authentication Header protocol are assigned a TCP/IP protocol number of 51.
Note: Consider using Authentication Header protocol when data confidentiality is not an issue. It allows you to minimize the cryptographic process, and therefore the required computing resources, executed against each IP packet to whatever is required for authentication only.
Encapsulated Security Payload protocol (ESP) The Encapsulated Security Payload (ESP™) protocol provides for data confidentiality using data encryption and optionally, data authentication. It uses the MD5 or SHA algorithm for authentication and the AES, DES or Triple-DES algorithm for data encryption. Here again, secret keys are shared between the two TCP/IP stacks acting as IPsec endpoints. The IPSec ESP protocol has the protocol number 50.
Figure 8-7 on page 141 describes the different formats of the IPSec IP packets per protocol and mode.
8.6.2 IPSec Security Association and key exchange
IPSec implements the concept of Security Association (SA), which is the set of information that each IPsec endpoint requires to operate with its IPSec peer. The SA provides the following information to the IPSec TCP/IP host: The IP addresses of the peer endpoints (this could be a range of addresses, as well). The secret keys to be used for the cryptographic processes. The IPSec protocols to be used (AH or ESP, or both). The IPsec mode to be used; that is, transport or tunnel mode (see the IPSec modes at 8.6.3, “Implementing network communication security with IPSec - IPSec modes” on page 140). The type of traffic to be protected. The type of algorithms to be used for encryption and authentication. The frequency of the refresh of the secret keys.
An SA is built following a negotiation phase that both endpoints perform when establishing the VPN. A specific protocol is used to automatically and securely establish the shared secret keys at both endpoints: the Internet Key Exchange (IKE) protocol.
VPNs with SAs that are automatically established by the IKE protocol are also called dynamic tunnels. In contrast, VPNs with SAs that are manually installed at both endpoints are static, or manual tunnels.
138 Designing for Solution-Based Security on z/OS Internet Key Exchange protocol The Internet Key Exchange (IKE) protocol is used by both endpoints to generate and securely install the shared secret keys to be used by the encryption and authentication processes, according to the TCP/IP stack IPSec policy. On z/OS, the IKE protocol is performed by the IKE Daemon (IKED) UNIX application, which is a two-phase process as explained here: Phase 1 This phase establishes a specific SA that will be used for the automatic and secure installation of the VPN encryption and authentication keys. As a preamble to any further process, the two IPSec endpoints authenticate themselves. There are currently two ways of getting this authentication done: by using a shared secret value that only these two TCP/IP host possess, or by using digital certificates. With digital certificates, the certificate contains the host IP address in one of its extension fields, and has been signed by a trusted Certificate Authority.
Note: Currently, most IPSec VPN devices use digital certificates for mutual authentication. The Simple Certificate Enrollment Protocol (SCEP), which was recently developed, allows devices that support the protocol to automatically access a Certificate Authority (that also supports the protocol), and to automatically obtain a certificate from this CA. This is particularly useful for installations (commonly found today) that contain hundreds or even thousands of VPN devices.
The z/OS PKI Services Certificate Authority supports the SCEP protocol.
Phase 2 This phase establishes the IPSec VPN SA. This SA contains the secret keys used to encrypt and authenticate data that will be flowing between the IPSec communication endpoints.
The IKE Daemon can be set up to periodically change, for security reason, these SAs (that is, to change the value of the secret keys). Typically, the IKE SA for phase 1 is changed less frequently (such as, a refresh every few days). In contrast, the VPN SA of phase 2 is changed more often (such as, a refresh every few minutes or hours).
The IKE two-phase process is illustrated in Figure 8-6.
Chapter 8. Overview of TCP/IP network security 139
IKE Phase 2 : secure installation/refresh of VPN data key (using IKE key for DES/T-DES encryption of data key) - typically occurs several times a day
IKE Phase 1 : secure installation of IKE key typically occurs once a day or once a week
Key server authentication via RSA signature or preshared key
certificate certificate
IKED IKE key Establishment IKED IKE Key IKE Key Sockets API Sockets API TCP/UDP y Encrypted data TCP/UDP IP/ICMP IP/ICMP y MAC-SHA and HMAC-MD5 VPN VPN Data Key Data Link Data Link authentication Data Key y DES and 3DES encryption z/OS TCP/IP stack y AES encryption Any system IPSec compliant stack Figure 8-6 IKE two-phase process
8.6.3 Implementing network communication security with IPSec - IPSec modes
An IPsec VPN can be used to establish end-to-end security in a network communication, or to protect only one segment of the network path taken by the communication, with the other parts having IP packets flowing unprotected. This is achieved by IPsec endpoints being set up to select the proper IPsec mode.
IPSec modes refer to the constitution of the IP packet that carries the AH or ESP protocol. The modes deal with the IP destination and source addresses that are actually set in the packet.
Transport mode In transport mode, the IP destination and origin addresses of the original non-IPsec packet are left unchanged. In other words, the TCP/IP hosts that issue and exploit the communication data are both ends of the VPN.
Tunnel mode In tunnel mode, the AH or ESP packet contains a preserved and encapsulated non-IPSec packet, but has a destination and source addresses that differ from the ones in the non-IPSec packet. The tunnel mode is used when only a part of the network is protected by IPSec, and border hosts are in charge of acting as IPsec gateways, encapsulating or decapsulating packets issued or received by the non-IPsec parts of the network.
Figure 8-7 summarizes the different formats of the IPsec IP packets, depending on the protocol and mode options.
140 Designing for Solution-Based Security on z/OS
SRC@, DST@,... Payload Original Datagram
AH New IP Hdr SRC@, DST@,... Payload AH-Tunnel Hdr
Authenticated
AH SRC@, DST@,... Payload AH-Transport Hdr
Authenticated
SRC@, DST@,... Payload Original Datagram
ESP ESP ESP ESP-Tunnel New IP Hdr SRC@, DST@,... Payload Hdr Trailer Auth
Encrypted Authenticated
ESP-Transport ESP ESP ESP SRC@, DST@,... Payload Hdr Trailer Auth
Encrypted Authenticated
Figure 8-7 The IPsec packets
By setting up IPSec hosts to use the proper IPSec mode, users can implement IPSec security on selected segments of a network, as shown in Figure 8-8.
Note that in Figure 8-8 on page 142, z/OS can be positioned as a data endpoint or a security endpoint.
Chapter 8. Overview of TCP/IP network security 141
Host-to-Host: End-to-End Security Association Legend
Data endpoint H1 Internet/intranet H2 Security endpoint
Connection Transport mode IPSec SA
Host-to-gateway: Protect segment of data path
H1 intranet intranet H2 G1 Internet/intranet G2
Connection Tunnel mode IPSec SA
Gateway-to-Gateway: Protection over Untrusted Network Segment
H1 intranet G1 Internet/intranet G2 intranet H2
Connection Tunnel mode IPSec SA
Figure 8-8 IPSec and network segments protection
NAT Traversal: Network Address Translation (NAT devices) are common network security elements, but they yield compatibility problems with the IPSec protocols: NAT devices are intended to modify the contents of IP packets, which adversely affects the packet integrity checking process of IPSec.
RFC 3947 and RFC 3948 have been developed to provide mechanisms that allow you to preserve the integrity of IP packets flowing through NAT devices (although some incompatibility cases are still unresolved). These mechanisms are designated by the generic name of NAT traversal support.
8.6.4 z/OS IPSec characteristics
Cryptographic algorithms The z/OS IPSec implements the following cryptographic algorithms: RSA for IKE. Diffie-Hellman, group 5 and 14, for IKE. With optional Perfect Forward Secrecy (PFS). HMAC-SHA and HMAC-MD5 authentication, DES and Triple-DES encryption. AES128 encryption (beginning with z/OS V1R8).
RSA, SHA-1, DES, T-DES, and AES128 (on System z9) are assisted by hardware if the hardware cryptography is enabled on the system (FC 3863 is installed on a z990 or z9 system).
142 Designing for Solution-Based Security on z/OS The NAT Traversal RFCs 3947 and 3948 are supported by the z/OS TCP/IP stack. zIIP Assisted IPSec Beginning with z/OS V1R9, or z/OS V1R8 with APARs PK40178 and OA20045, users of z9 systems with one or several zIIP specialty engines installed can move most of the IPSec processing from the general purpose processors to the zIIPs. This saves CP MIPS that would have otherwise been consumed.
No IPSec IPSec with no zIIP IPSec with zIIP
Application Application
Application IPSec processing IPSec processing IPSec processing
TCP/IP TCP/IP TCP/IP (SRB Mode)
General Purpose CP General Purpose CP General Purpose CP zIIP
Candidate for zIIP Assist
Figure 8-9 IPSec zIIP processing
This offloading to zIIPs is optional and is selected using a configuration statement in the TCPIP.PROFILE that triggers the Communications Server to request z/OS to direct the IPSec enclave SRB processing to available zIIPs. The statement to use is:
GLOBALCONFIG ZIIP IPSECURITY - to have the eligible work directed to the zIIP
GLOBALCONFIG ZIIP NOIPSECURITY - this is the default value
Note that the IPSec workload is competing for zIIP cycles with other zIIP-eligible workloads (such as DRDA® processes). z/OS Network Security Services infrastructure Beginning with z/OS V1R9, users can implement a z/OS Network Security Services (NSS) client-server infrastructure that provides centralized network security services for a set of z/OS images, in order to centralize and reduce the complexity of configuration and deployment. Note the following points: NSS allows central administration of RACF certificates and private keys used by the IKE daemons in the different z/OS instances. This eliminates the need to distribute IKE certificates to the different daemons, and also provides the ability to select a single z/OS instance to perform the required RSA signature workload. It also allows selection of a single z/OS instance to act as an IPsec management hub, where an IPsec administrator can enter commands intended for the NSS client z/OS instances, and monitor the IPSec activity in the clients using the Network Monitor Interface.
Chapter 8. Overview of TCP/IP network security 143 The Network Security Services Daemon (NSSD) has the role of an NSS server running on z/OS. The z/OS Internet Key Exchange Daemon (IKED) is enhanced with NSS client functionality. One NSS client supports all TCP/IP stacks in a single z/OS instance. The choice of local or centralized IKE services can be made individually for each TCP/IP stack in a z/OS instance. That is, in the IKE configuration file, Stack A can be configured to use the local IKE services and Stack B can be configured to use the centralized NSS.
Note that the NSS infrastructure implementation is not dependent upon sysplex technology, so it can be set up in a non-sysplex, within sysplex, or cross-sysplex environment. Figure 8-10 illustrates a schematic view of the NSS infrastructure.
secure TCP connections z/OS image x Certificates and private keys for z/OS images 1 to n Centralized image 1 monitoring Network IKE RACF Daemon Security Keyring nss.conf Services iked.conf
Centralized RACF certificate Stack Stack administration One .. Eight
z/OS image n IKE peer IKE Daemon
iked.conf
Stack Stack One ... Eight
Figure 8-10 z/OS Network Security Services infrastructure
8.7 Application Transparent TLS
Both SSL and the newer TLS protocols were originally designed to be supported by dedicated code imbedded in applications. z/OS provides ways of simplifying the design of SSL/TLS-enabled applications by offering System SSL APIs and libraries. An SSL/TLS-enabled application on z/OS can leave the management of SSL protocol and data protection-related processes to System SSL.
This vastly reduces the amount of coding in these applications, and guarantees that every application will obtain consistent and up-to-date support of SSL and TLS protocols. System SSL also allows you to use specific z/OS facilities (such as RACF key rings and System z hardware cryptography) transparently to the application.
Application Transparent TLS (AT-TLS) is a z/OS Communication Server function, available beginning with z/OS V1R7, that provides SSL and TLS support on behalf of the application. This means that applications are not required to have been designed to support SSL or TLS in order to benefit from communication protection provided by these protocols; the SSL or TLS protocol is performed at the z/OS TCP/IP stack level.
144 Designing for Solution-Based Security on z/OS Note that an z/OS application that benefits from the AT-TLS support can be a server or client application. It is, however, still mandatory that the partner application does support SSL or TLS. If running also on z/OS V1R7 or above, the partner application can obtain AT-TLS support to handle its side of the SSL/TLS communication.
8.7.1 AT-TLS implementation
AT-TLS is implemented in the transport layer of the z/OS TCP/IP stack, and is activated by loading the proper AT-TLS policy in the stack. A schematic view of the implementation is given in Figure 8-11.
As you see, it shows that the SSL communication endpoint is actually the z/OS TCP/IP stack, as opposed to the usual case where the endpoint is the application itself. The data exchanged in the AT-TLS case between the z/OS TCP/IP stack and the local application is simply the normal flow of non-encrypted data.
Note that the AT-TLS support in the z/OS TCP/IP stack has the following characteristics: It relies on the exploitation of System SSL, and therefore obtains the inherent benefits of up-to-date support of the protocols, and the imbedded exploitation of hardware cryptography. It can use certificates in UNIX files (the System SSL .kdb files) or in RACF key rings. AT-TLS can also perform SSL/TLS authentication (that is, using a digital certificate on behalf of a client application). It offers ways for an application to interact with the AT-TLS process via an SIOCTL API. This, however, assumes that the application has been designed to exploit this API and is therefore an AT-TLS aware application. Using this API, an AT-TLS-aware application can control when the communication is to switch to AT-TLS supported SSL/TLS communication. It can also obtain status information about the ongoing SSL/TLS communication, or get access to the digital certificate sent by the partner application. Applications that obtain AT-TLS support can therefore be classified as: AT-TLS basic applications These applications do not support, by any means, SSL or TLS communications. AT-TLS-aware applications These applications can exploit advanced AT-TLS features using new SIOCTTLSCT ioctl calls. They can also extract information such as the SSL/TLS policy in effect, the handshake results, the partner application’s x.509 digital certificate and the RACF user ID associated with the certificate. AT-TLS controlling applications In addition to using the SIOCTTLSCT ioctl calls, these applications can control when to start or reset the SSL/TLS session, and when to reset the cipher data in use by the session.
Chapter 8. Overview of TCP/IP network security 145
Application AT-TLS aware Basic AT-TLS Transparent TLS policy flat file and controlling applications applications Optional APIs for TLS-aware applications to control start/stop of Sockets TLS session Policy Agent System SSL calls AT-TLS
TCP RACF certificate services
IP Networking Layer
Network Interfaces
SSL/TLS communication with the partner application
Figure 8-11 AT-TLS implementation
In summary, z/OS AT-TLS offers the following support: Full transparency or semi-transparency to applications – Support existing applications without change – Allow applications to optionally exploit or control advanced features: • simple ioctl • extract status, certificate, associated user ID • permit clear text negotiation prior to starting secure connection Imbedded support of – RACF key rings – System SSL libraries – Hardware cryptography Multiple protocols supported • TLS (SSL V3.1) • SSL V3.0 • SSL V2
8.7.2 The AT-TLS policy
Users must specify, in the AT-TLS policy, all the parameters that AT-TLS will need to conduct an SSL/TLS-protected conversation on behalf of the applications. These parameters will be used, for most of them, to drive System SSL.
The AT-TLS policy is defined in the Policy Agent main configuration file and is structured as follows: The name of a file containing the AT-TLS policy objects shared across TCP/IP stacks is specified with the CommonTTLSConfig statement.
146 Designing for Solution-Based Security on z/OS In turn, these shared objects are specified in this file with: – TTLSRule statements – TTLSGroupAction statements – TTLSEnvironmentAction statements – TTLSConnectionAction statements The name of a file containing the AT-TLS policy for one TCP/IP stack is specified with the PEPInstance statement. This TTLSConfig statement points at a file that contains the AT-TL.
Using the policy statements, users can also set up the criteria that the TCP/IP stack is to use to trigger (or not trigger) the AT-TLS support for an application. These criteria are summarized in Table 8-1.
Table 8-1 AT-TLS Policy conditions Criteria Description
Resource attributes
Local address Local IP address
Remote address Remote IP address
Local port Local port or ports
Remote port Remote port or ports
Connection type attributes
Connection direction - Inbound (applied to first Select, Send, or Receive after Accept) - Outbound (applied to Connect) - Both
Application attributes
User ID User ID of the owning process or wildcard user ID
Jobname Jobname of the owning application or wildcard jobname
Time condition
Time, Day, Week, Month When filter rule is active
8.7.3 z/OS AT-TLS aware applications
As of z/OS V1R9, the z/OS TN3270 server, as well as the FTP server and client applications, have been upgraded to run optionally as AT-TLS controlling applications, as an alternative to their native support of SSL/TLS with System SSL. If the user selects the AT-TLS mode of operation for the TN3270 server and the FTP server or client applications, these services indirectly benefit, via AT-TLS, from the latest System SSL functions available in their hosting z/OS instance.
z/OS FTP client and server The z/OS FTP native System SSL support does not provide all the functions of System SSL, such as using LDAP servers for certificate revocation lists (CRLs). FTP does not also communicate to system SSL a specific certificate label in a key database or in a RACF key ring, and therefore can only operate with the default certificate.
Chapter 8. Overview of TCP/IP network security 147 Another System SSL function that is not natively exploited by FTP is the capability of refreshing the SSL/TLS session keys during the lifetime of a session.
The z/OS FTP client and server can be configured to use AT-TLS instead of their native System SSL support beginning with z/OS V1R9. In this case, FTP acts as a controlling AT-TLS application and requires the ApplicationControlled On statement in the AT-TLS policy.
Using AT-TLS allows all System SSL parameters supported by AT-TLS to be configured for FTP operations. For example, multiple LDAP servers can be configured, or a certificate label can be configured instead of the default certificate. AT-TLS can also be configured to refresh the session key on a connection.
The configuration statement TLSMECHANISM in the FTP.DATA data set is used to select the AT-TLS support (ATTLS) or the default System SSL support (FTP).
8.7.4 z/OS TN3270 server
As for FTP, the TN3270 native support of System SSL does not include functions now available in System SSL. The TN3270 server can be configured, beginning with z/OS V1R9, to use AT-TLS as an alternative to using its native System SSL support. Users can select the use of AT-TLS at the port level with the parameter TTLSPORT in the port definition statement of TN3270.
When selecting to use AT-TLS, users can exploit, via the AT-TLS policy parameters, the following capabilities: Specifying different key rings on different ports and even different key rings on the same port Refreshing security parameters without having to stop or restart the secure ports (this is particularly useful when the default certificate expires and must be replaced). Specifying backup LDAP servers to get CRL from. Exploiting client emulators that support session ID caching and renegotiation of a cipher key during an active secure session. Specifying a certificate label to be used instead of the default key ring certificate.
8.8 z/OS IPSec or AT-TLS
At this point you may be wondering, should you use z/OS IPSec or AT-TLS functionality? This is a valid question, especially if you have non-AT-TLS-aware applications. The answer is specific to each use case.
This section offers a comparison of the characteristics of each function, which may help you to decide which function is most appropriate for your situation. IPSec is intended to protect traffic between two TCP/IP stacks, absolutely transparently to the applications, and can potentially protect any TCP/IP protocol that TCP/IP datagrams are carrying. It is an industry-wide adapted protocol, and you can expect interoperability between different platforms. AT-TLS is intended to protect traffic between specific client and server applications, as well as between the TCP/IP stacks that these applications are bound to. For application native
148 Designing for Solution-Based Security on z/OS SSL/TLS support, protection is only provided on data transported by regular TCP datagrams. The AT-TLS function only pertains to a z/OS endpoint; the other endpoint is required to support SSL or TLS (but can also be another z/OS endpoint using AT-TLS). It is also expected that SSL or TLS interoperability will not be a problem.
Table 8-2 lists the differences between IPSec and AT-TLS that may affect your decision regarding which function is most appropriate for your environment.
Table 8-2 Differences between IPSec and SSL/TLS protection IPSEC AT-TLS
Traffic protected with data All protocols TCP authentication and encryption
End-to-end protection Yes Yes
Segment protection Yes No
Scope of protection Security association TLS session 1) all traffic 1) single connection 2) protocol 3) single connection
How controlled IPSec policy AT-TLS policy 1) z/OS responds to IKE peer 1) For handshake role of server, 2) z/OS initiates to IKE peer based on responds to TLS client based on policy outbound packet, IPSec command, or 2) For handshake role of client, policy autoactivation initializes TLS based on policy 3) Advanced function applications
Requires application modifications No No, unless advanced function needed 1) Obtain client cert/user ID 2) Start TLS
Type of security Device-to-device Application-to-application
Type of authentication Peer-to-peer 1) Server-to-client 2) Client-to-server (opt)
Authentication credentials 1) Pre-shared keys X.509 certificate 2) X.509 certificate
Authentication principals Represents host Represents user
Session key generation/refresh Yes with IKE TLS handshake No with manual IPSec
8.9 Intrusion detection and z/OS Intrusion Detection Services
This section presents general concepts related to intrusion detection, as well as details about z/OS Intrusion Detection Services (IDS) functions and components.
8.9.1 Intrusion detection overview
In network security terminology, “intrusion” designates anomalous, and potentially malicious, activities. The objective of an intrusion may be to acquire unauthorized information, or to gain unauthorized use of a system as a stepping stone to further intrusions. It can also be to
Chapter 8. Overview of TCP/IP network security 149 adversely affect business by rendering a network, system, or application unusable. Most intrusions follow a pattern of events beginning with information gathering, followed by attempted access, and then destructive attacks.
Note: In the distributed world, “intrusion” designates both malicious activities at the network level and penetration of the system itself.
Within the scope of this chapter, however, intrusion is considered as occurring at the network level only because on z/OS, platform penetration protection is performed by RACF.
An intrusion detection service can be network-based, in which case it analyzes data flowing over a segment of the network. Alternatively, it can be host-based, in which case it performs at the segment endpoint (that is, at the TCP/IP stack of a network host system). It can also be a mix of both technologies, comprising sensors located both in network segments and in the host’s TCP/IP stacks. The sensors (or “probes”) are then all connected to a focal point device that centralizes the reportage of alert conditions they send.
These various types of intrusion detection systems are explained in greater detail in the following sections.
8.9.2 Network-based intrusion detection
Intrusion detection probes analyze network data against known “signatures”, that is, IP datagram headers or data patterns known to be used for intrusion. Because the probes are scattered over the network, and a single probe view is usually not enough to assess the real danger of the observed IP traffic, network-based intrusion detection also involves the use of correlating devices, such as the IBM Tivoli Security Operations Manager (see “Tivoli Security Operations Manager” on page 73). These devices raise an alert if the observed traffic is deemed to be a real alarm (not a “false-positive,” in intrusion detection terminology) based on information collected from the probes.
8.9.3 Host-based intrusion detection
Host-based intrusion detection relies on additional capabilities in the host TCP/IP stack to analyze the received IP packets against known intrusion characteristic patterns. Host-based intrusion detection offers the following advantages when compared to network-based intrusion detection: Evaluation of inbound IPSec data, because the data is first decrypted in the target stack before being submitted to intrusion analysis. Avoidance of the overhead of per-packet evaluation against a table of known attacks, because the target stack’s internal processes detect the anomalous condition and then make a decision based on current intrusion detection policy directives. Determination of statistical anomalies based on the target stack internal thresholds or state data. Direct application of prevention methods in the target stack based on the provided intrusion detection policy. Fewer false positives (globally speaking).
However, installations can exploit both implementations by integrating network-based and host-based intrusion detection into their network intrusion detection infrastructure.
150 Designing for Solution-Based Security on z/OS 8.9.4 z/OS Intrusion Detection Services
z/OS Intrusion Detection Services (IDS) operates in the z/OS TCP/IP stack and protects against threats such as: TCP/IP ports scanning and information gathering Attacks against the stack Flooding (both TCP and UDP)
IDS works at both the IP and transport layers. IDS has access to information such as memory and CPU usage, connection state information, internal data queue lengths, and packet-discard rates and reasons. It can therefore make informed decisions based on statistical anomalies to detect and stop attacks.
When an attack is detected, event records can be written to Syslogd or to the local console, or a sampling of packet traces can be taken based on the policy defined to the Policy Agent. In z/OS Communications Server, the Traffic Regulation Monitoring Daemon (TRMD) handles event recording for IDS by sending log data to the z/OS Syslogd.
IDS policies are defined by the administrator using the IBM Configuration Assistant for z/OS Communication Server GUI tool and installed in the Policy Agent. The Policy Agent decodes the policy information and installs it in the TCP/IP stack to drive the IP and transport layers processes for the detection and prevention of intrusion. Figure 8-12 on page 151 illustrates the IDS setup.
IDS POLICY
Log Events
POLICY TRMD SYSLOGD AGENT
SOCKETS API Install IDS Event Policy in Intrusion Messages to stack Event Console TRANSPORT LAYER TCP/UDP
IP NETWORKING LAYER
TRACES NETWORK INTERFACES Trace Suspicious ATTACK Activity
Figure 8-12 z/OS IDS setup
Chapter 8. Overview of TCP/IP network security 151 8.10 z/OS IP Security or IDS data collection
z/OS IP Filtering, IPSec, and IDS functions are designed to log data as messages intended for the Syslog daemon (Syslogd) facility of z/OS.
8.10.1 z/OS Syslogd
The Syslogd UNIX application is used to collect the messages issued by the Traffic Regulation Management Daemon (TRMD) component of the z/OS TCP/IP stack. Depending on the directives set up in its configuration file, Syslogd reads and logs messages by sending them to the z/OS system console, by writing log files or SMF records, or by sending the messages to other specified machines or users.
Many components in z/OS send messages to Syslogd. These messages are tagged with a facility name (which is used to identify the origin of the message) and a priority code (to indicate in which predefined circumstance this message is issued).
The Syslog daemon in z/OS can be set up to only accept messages issued with specific facility names and priority codes. Likewise, the facility name and priority code can be used to sort out messages and select their destination accordingly. The facility names pertaining to z/OS IP Security and IDS are listed in Table 8-3.
Table 8-3 z/OS syslog facility names for IP Security and IDS Application Syslogd record Primary syslog Other syslog facility identifications facility
AT-TLS TTLS daemon auth
IKE IKED local4 none
TRMD TRMD daemon (used for IDS local4 (used for IP logging) Security logging)
The z/OS Syslog facility supports these priority codes: 0 Emergency 1 Alert 2 Critical situation 3 Error 4 Warning 5 Notice 6 Information 7 Debug
The message priority code is set by the application logging into Syslogd, and the application is expected to abide by these definitions. That is, an application enabled to deliver error messages and warning messages will log messages with priority codes 3 and 4.
Destination of the messages
Syslogd can be configured to forward received messages to the following destinations, and as mentioned, with a selection based on the facility name and priority code: z/OS UNIX file (/file) A syslog daemon on another host (@host) List of local users (user1,user2,...) The z/OS system console (/dev/console)
152 Designing for Solution-Based Security on z/OS A specific z/OS operlog stream (/dev/operlog) An SMF type 109 record ($SMF)
8.10.2 IDS management and alerts
z/OS IDS can use NetView® z/OS to propagate information about an alert condition (this requires at a minimum NetView z/OS V5R1with PTF UA11043). This provides the ability to: Trap IDS messages from the system console or Syslog, and take predefined actions based on IDS event type, such as: – Route IDS messages to designated NetView consoles – Send e-mail notifications to the security administrator – Execute trmdstat to issue an IDS report and attach output to e-mail – Issue predefined commands Send TEC events to Tivoli Security Operations Manager for enterprise-wide correlation and analysis of intrusion events. Format the file provided by z/OS Communications Server to convert Syslog messages to TEC events Control the IDS message volume with threshold values Generate trmdstat reports and e-mails to the defined set of security administrators based on timer event
8.11 Complementing z/OS network security
Although the IP security and IDS technologies available in the z/OS TCP/IP stack fit for an intranet environment, an Internet connection will require the additional protection provided by devices, such as firewall devices, external to z/OS. An approach for a System z fully integrated solution is illustrated in Figure 8-13.
Internet Internet Production Intranet DMZ Zone
Restricted
Client
Management Zone
Uncontrolled Controlled Secured Controlled
Figure 8-13 Complementing z/OS network security
Chapter 8. Overview of TCP/IP network security 153 As shown in the figure, the System z physical machine hosts three logical partitions: The Internet-facing LPAR, on the left side, runs Linux for System z and hosts proper network security functions such as advanced firewall functions and, in this example, an HTTP authentication reverse proxy (such as the IBM Tivoli Access Manager for e-business product WebSeal). This logical partition can be protected by external devices, depending on the usage context and the standards of the installation. The LPAR in the middle hosts a WebSphere Application Server instance that processes requests and obtains, through access control, the data required by users on the Internet. The LPAR on the right contains the installation production system. This is the “safest” partition from the perspective of network threats, because network communications are filtered and controlled by the Linux partition, and mediated by the middle partition.
Network communication between these LPARS is handled by the PR/SM hipersocket feature, which acts as a local Ethernet network to the TCP/IP stacks of the LPARs. Using hipersockets contributes to increased security because they are not physical networks that an intruder can tap into; instead, hipersockets definitions are part of the system IOCDS definition.
Because hipersockets appear to be Ethernet networks, z/OS TCP/IP stacks connected to hipersockets can exploit z/OS network security functions. In Figure 8-13, for example, the connection between the Linux partitions and the z/OS partitions is protected on the z/OS side by RACF access control of TCP/IP resources, IP filtering and IDS (shown as the FW box).
Also notice that IPSec VPN protection is illustrated in the figure. In many cases, that would probably be in AH mode only (that is, for authentication of a genuine partner), because the use of hipersockets would generally not require data secrecy like a real network would.
In this figure, the Linux partition constitutes the network DMZ (de-militarized zone).
154 Designing for Solution-Based Security on z/OS
9
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics
In this chapter we explain how non-z/OS security models are supported on z/OS. As an example, we use the implementation of the J2EE and Web Services models with WebSphere Application Server for z/OS.
© Copyright IBM Corp. 2008. All rights reserved. 155 9.1 Security environments and WebSphere Application Server for z/OS
J2EE and Web Services support, as provided via WebSphere Application Server for z/OS, is based on several different programming model layers, each with its own specific security model. In this section we provide an overview of this layered approach as implemented in WebSphere Application Server for z/OS.
For more complete information about WebSphere Application Server security setup, refer to WebSphere Application Server for z/OS, Securing Applications and Their Environment, SA22-7961.
9.1.1 WebSphere Application Server and z/OS - overview
z/OS does not provide security APIs that J2EE or Web Services applications can directly use. It does, however, optionally extend J2EE and Web Services security by providing z/OS-controlled resources that back up the J2EE or Web Services security model.
From an application perspective, as shown in Figure 9-1, the required services are provided by the WebSphere Application Server runtime. The runtime is a set of z/OS started tasks that each run with a z/OS RACF user ID, and operate according to the z/OS security model.
z/OS WebSphere Application Server runtime environment Web Services Security Application Server Node 2 WebSphere Security
J2EE Security API J2EE scalable application server Java 2 Security Java http Servant RMI/IIOP Principal JVM JMS Controller J2EE application region Resource Connector z/OS userid / UID 3
TCP/IP 1
z/OS userid / UID MVS userid / UID zOS Security and SAF z/OS userid / UID MVS userid / UID
Figure 9-1 WebSphere Application Server for z/OS security implementation
We can therefore distinguish the following different security environments in this implementation: The z/OS environment In this case we are using the z/OS regular security services to secure the execution of the WebSphere Application Server Controller and Servant region address spaces and the
156 Designing for Solution-Based Security on z/OS JVM they host. This approach relies on the usual RACF mechanisms for identifying started tasks and controlling their access to z/OS resources. As long as the WebSphere Application Server code handles its own, specific security-related entities (such as Java and J2EE subjects and their privileges regarding Java or J2EE resources) within its runtime, the z/OS security mechanisms are not directly involved in the relevant processes. Note, however, that when a user requests that WebSphere Application Server processes translate into a request for z/OS-controlled resources (typically using the JCA component connecting to a transaction server or database manager running on z/OS, or performing a file access), then the z/OS security mechanism once again applies, based on the RACF user ID that is associated to the request issued from WebSphere Application Server. There are different security models involved in the (to use a generic term) “WebSphere Application Server runtime environment” shown in Figure 9-1: – The z/OS JVM is located at the “bottom” of this security environment stack. It performs the optional Java 2 Security mechanisms on the basis of the code base and Java principal that is making requests to access Java resources controlled by the JVM security policies. The JVM also provides APIs, such as the Java Cryptographic Extension (JCE) cryptographic APIs or the Java Secure Socket Extension (JSSE) API, which applications can use to invoke cryptographic services. – The J2EE container of WebSphere Application Server provides the J2EE security services and APIs that can be used by J2EE application components to proceed with caller authentication and resource access control. – The WebSphere Application Server has its own security services that make up the underlying infrastructure for achieving secure communications, proper access to user registries and authorization data, and the secure propagation of J2EE application-originated requests to environments external to the J2EE container. – Web Services security becomes as an additional layer when users exploit the Web Services technology via the Web Services support embedded into WebSphere Application Server. RACF profiles can be used to protect some resources specific to WebSphere Application Server for z/OS. This explained in further detail in 9.1.3, “WebSphere Application Server-specific RACF protected resources” and in 9.3.2, “Using SAF for authentication and authorization - summary” on page 169.
9.1.2 WebSphere Application Server for z/OS communication flows
The communication flows into and out of WebSphere Application Server occur as TCP/IP communications transported by HTTP, RMI/IIOP, or JMS protocol. These communication protocols can be protected at the transport level by using the lower-level SSL or TLS protocol. In addition to providing for data confidentiality and integrity, SSL and TLS can also carry their own authentication data in the form of digital certificates (referred to as “transport-level” authentication rather than application-level authentication).
HTTP The HTTP protocol is used as a client-server transport protocol for communicating with the Web components of J2EE applications (that is, servlets or JSPs). HTTP is also used to transport the SOAP messaging used for Web Services.
In addition to a pure data payload, HTTP protocol allows the transmission of many headers that contain information meaningful to the HTTP client or server internal processes. HTTP
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 157 headers have been standardized to carry security information such as requests for authentication from the server side and authentication data from the client side.
Filtering HTTP communications The HTTP protocol is not a TCP/IP protocol in itself. Instead, in its basic or in its SSL/TLS protected form, it is composed of TCP (protocol number 6) IP datagrams. Therefore, it cannot be specifically filtered on the basis of the protocol number, but only on the destination, origin address, or port.
Remote Method Invocation/Internet Inter-ORB protocol (RMI/IIOP) RMI/IIOP is intended for client-server communications with the EJB™ application components that run in the WebSphere Application Server container. It is operated via Java APIs on the client and server side. RMI/IIOP can run with SSL or TLS protection, and can therefore benefit from the transport layer client authentication.
CSIv2 RMI/IIOP can also transport data pertaining to the Common Secure Interoperability V2 protocol. The CSIv2 protocol provides the following mechanisms: An authentication mechanism that carries the client’s identity and password to the server. This specific information is transported in the “Supplemental Client Authentication Layer” of CSIv2 messages. An identity assertion mechanism that can propagate a caller identity with the implicit indication that this identity has already been authenticated by an upstream server. This is the “Security Attribute Layer” of CSIv2. The asserted identity can be carried over in the form of a local operating system user identity, an LDAP distinguished name, or a digital certificate.
Note that using CSIv2 does not preclude optionally protecting the communication with SSL or TLS. In fact, these can work together because SSL/TLS can be used to perform client system authentication while CSIv2 carries a user-asserted identity.
Filtering RMI/IIOP communications RMI/IIOP is not a specific TCP/IP protocol; it is comprised of TCP datagrams.
Java Message Service (JMS) The Java Message Service (JMS) is an API intended to provide messaging facilities to Java applications in order to exchange messages. The API invokes an underlying provider in charge of managing messages and queues. In WebSphere Application Server for z/OS, the JMS provider is WebSphere MQ.
Filtering JMS communications The message service is not a specific TCP/IP protocol; it comprised of TCP datagrams.
158 Designing for Solution-Based Security on z/OS
SSL/TLS support in WebSphere Application Server for z/OS: Prior to WebSphere Application Server 6.1, the z/OS System SSL library API was used to support WebSphere
Application Server Controller region SSL/TLS communications.
As of WebSphere Application Server Version 6.1, System SSL is used only for the Daemon address space. All other WebSphere Application Server components use the Java Secure Socket Extension (JSSE) for SSL/TLS communications.
System z hardware cryptography support is still available to the extent that the IBMJCECCA cryptographic provider has been selected as a provider for the JCE API. IBMJCECCA also supports a wide variety of key stores, including RACF key rings.
Note: RACF profiles in the CBIND class can also be used to established whether inbound communications can be accepted. This is discussed in “CBIND class”.
9.1.3 WebSphere Application Server-specific RACF protected resources
As shown in Figure 9-1, in addition to the usual z/OS resources that are protected with RACF, some resources specific to WebSphere Application Server for z/OS can also be protected by RACF. The following RACF classes and profiles are used in the context of establishing the security environment for the WebSphere Application Server runtime.
SERVER class SERVER class is used to control access to the controller region by a servant region.
CBIND class CBIND profiles control inbound access via the IIOP/RMI and CSIv2 protocols to WebSphere Application Server for z/OS servers (including access from Web servers running the WebSphere Application Server plug-in and access to objects in the servers) from Java application clients and other WebSphere Application Server servers.
BBO.SYNC in the FACILITY class; BBO.SYNC in the SURROGAT class This profile controls whether the function Enable Synch to OS Thread is allowed; this function is discussed in more detail in 9.2.5, “Synchronize to OS thread” on page 166.
Access to this function is granted if all of the following conditions are met: Applications that are to invoke the function must be tagged in their deployment descriptor with an env-entry containing the com.ibm.websphere.security.SyncToOSThread property set to true. The WebSphere Application Server Security configuration must have Sync to Thread enabled at the administrative console. The RACF administrator has granted the following permissions: The controller region RACF user ID must have CONTROL ACCESS to the BBO.SYNC resource in the FACILITY class, or the controller region RACF user ID must have READ ACCESS to the BBO.SYNC resource in the FACILITY class and the servant region RACF user ID must have READ ACCESS to the BBO.SYNC.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 159 BBO.TRUSTEDAPPS in the FACILITY class WebSphere Application Server servers may have to create a z/OS security context (such as a RACF Object (RACO) control block) to represent an application user, without using the user’s credentials (as it would be the case if the user’s identity had been asserted). When this profile is defined, only WebSphere Application Server servers that have READ access to the resource can invoke z/OS to create such a security context.
9.2 WebSphere Application Server user identification and authentication
A WebSphere Application Server client can be a user, a machine, or an application. An authentication mechanism in WebSphere Application Server typically collaborates closely with a user registry. The user registry is the user and group account repository that the authentication mechanism consults with when performing authentication.
9.2.1 WebSphere Application Server authentication mechanisms
The WebSphere Application Server authentication mechanism is responsible for creating a credential that is an internal product representation of a successfully authenticated client user. Not all credentials are created “equal”; the abilities of the credential are determined by the configured authentication mechanism. Although several authentication mechanisms are available with WebSphere Application Server, only a single active authentication mechanism can be configured at a given time.
The active authentication mechanism is selected when configuring WebSphere global security. WebSphere Application Server for z/OS Version 6 supports the following authentication mechanisms: Simple WebSphere Authentication Mechanism Simple WebSphere Authentication Mechanism (SWAM) is deprecated beginning with WebSphere Application Server V6. We recommend that you replace it, using instead the Light-Weight Third Party Authentication (LTPA) authentication mechanism. Light-Weight Third Party Authentication Lightweight Third Party Authentication (LTPA) is intended for distributed multiple-application server and machine environments. The authentication credentials contain an LTPA token that supports credential forwarding and single sign-on (SSO). LTPA can support security in a distributed environment through the use of cryptography. The LTPA mechanism exploits cryptography to encrypt, digitally sign, and securely transmit authentication-related data, and later decrypt and verify the signature. LTPA tokens are also supported by Lotus® Domino® and TAM WebSEAL. As mentioned, it is now recommended to always use LTPA as a replacement for Simple WebSphere Authentication Mechanism.
The Java Authentication and Authorization Services (JAAS) framework The WebSphere Application Server underlying authentication infrastructure is based on exploitation of the Java Authentication and Authorization services (JAAS) framework. In the framework, pluggable login modules are called, using a specified set of interfaces, to process the client’s identity and authentication data and verify their validity against a user registry. In this respect, the JAAS framework looks like the Pluggable Authentication Module (PAM)
160 Designing for Solution-Based Security on z/OS approach familiar to UNIX users in that JAAS login modules can be placed into a PAM-like chain.
JAAS is an integral part of Java 2 Security that WebSphere Application Server exploits for authentication services, thus providing users with a plug-in point to insert default or customized authentication modules. JAAS login modules can be designed to perform principal and credential mapping, and custom security token and custom-credential processing. They can also provide error-handling functions.
The JAAS framework defines three sets of classes, as listed here. The common classes: –Subject – Principal – Credential The authentication classes: – LoginContext – LoginModule – CallbackHandler – Callback The authorization classes: – Policy – AuthPermission – PrivateCredentialPermission
JAAS subject A JAAS subject can be thought as a container populated by the JAAS login modules as a result of a successful user authentication. It contains user information, including the groups that the user belongs to, in the form of principal and credentials: WSPrincipal – basically a Java Principal WSCredential – an object with various security attributes about users, groups, user IDs, realm, and so on
Optional custom data may also be included, as provided by the login modules.
WebSphere Application Server JAAS login configuration Default JAAS login modules are delivered in WebSphere Application Server for z/OS, and they are implicitly selected with the following preconfigured system login configurations. DEFAULT This login configuration handles the logins for inbound requests that are made by most of the protocols and internal authentications other than RMI or Web inbound. LTPA_WEB This processes login requests to components in the Web container, such as servlets and JavaServer™ pages (JSP™) files. RMI_INBOUND This login configuration handles logins for inbound RMI requests. Typically, these logins are requests for authenticated access to Enterprise JavaBeans™ (EJB) files. RMI_OUTBOUND The RMI_OUTBOUND login configuration is a plug point for handling outbound requests. WebSphere Application Server uses this plug point to create the serialized information
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 161 that is sent downstream based on the invocation Subject passed in and other security context information such as propagation tokens. Simple WebSphere Authentication Mechanism (SWAM) This processes login requests in a single server environment when used as the authentication method. WEB_INBOUND This login configuration handles logins for Web application requests, which include servlets and JavaServer Pages (JSP) files. This login configuration can interact with the output that is generated from a trust association interceptor (TAI), if configured. The Subject that is passed into the WEB_INBOUND login configuration might contain objects that are generated by the TAI.
Figure 9-2 illustrates the authentication infrastructure of WebSphere Application Server. The right side of the figure shows the different user registry types that WebSphere Application Server supports; these are discussed in the next section.
WebSphere Application Server
CSIv2, TCP/IP, SSL/TLS Authentication Java client Enterprise beans module Federated authenticator repositories Basic or 1 4 Token credentials SWAM 3 module Local Received 5 credentials OS credentials 2 ORB Standalone Current object Login LDAP module registry credentials 5 2 Standalone Received custom HTTP, SSL/TLS credentials 4 LTPA registry module Web client Web 3 1 authenticator Basic, token or certificate
Figure 9-2 WebSphere Application Server authentication mechanisms
Whatever the login information used, users can provide their initial authentication data in one of the following ways: Basic Authentication (UserID/Password). Form-based login - The user is redirected by WebSphere Application Server to a custom page where the user types in username and password. SSL/TLS authentication using a digital certificate.
After initial authentication has been performed, a WebSphere Application Server instance can give the authenticated user an LTPA token that can then be replayed as an authentication credential within its lifetime period.
162 Designing for Solution-Based Security on z/OS 9.2.2 WebSphere Application Server user registries
Information about users and the groups they belong to reside in a user registry. WebSphere Application Server is implemented to support multiple local operating system-based or external operating environment-based user registries. When configuring WebSphere Application Server, the user must select a single user registry. The user registry can be local or remote.
The choices for user registry with WebSphere Application Server for z/OS are: SAF-based local registry (default) If the SAF-based local registry is selected, then the WebSphere Application Server container calls RACF for validation of a user ID and password, or for the mapping of the client digital certificate validated by the SSL/TLS support in WebSphere Application Server. Standalone Lightweight Directory Access Protocol (LDAP) registry LDAP can be either a local or remote registry. WebSphere Application Server comes with preselected sets of filters that can be used to retrieve the LDAP entry that corresponds to the user identity. This is further discussed in 9.4, “Using LDAP as a user registry for WebSphere Application Server” on page 172. Standalone custom user registry A custom user registry refers to one that is designed and set up by the user to meet unique registry needs. A standalone custom-implemented registry uses the UserRegistry Java interface as provided by WebSphere Application Server. Federated repositories WebSphere Application Server V6.1 provides applications with a common model, secure access to various brands and types of repositories, and the ability to use repositories with existing data. The single model includes a set of organizational entity types and their properties, a repository-independent API, and a Service Provider Programming Interface (SPI) for plugging in repositories.
The Federated repositories model is intended to offer: – Extended User Attribute. As part of its offering, it is designed to support the ability to chain registries if duplicate IDs do not exist across the chained user registries. The ability to use multiple repositories simultaneously in a realm. – A single model for user and group information. – Support for the logical joining of entries across multiple user repositories. – Support for a property extension repository.
9.2.3 Other WebSphere Application Server identity considerations
The WebSphere Application Server authenticates the user identity and creates a representation of the user with a Java Authentication and Authorization Service (JAAS) Subject. A Subject contains one or more Principals (which are technology-dependent
representations of the authenticated user identity) and Credentials to be used when building a security context.
User identity The access control decisions to be made within the WebSphere Application Server for z/OS at different levels of the infrastructure are based on one of the following identities.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 163 J2EE identity The J2EE identity is the user identity authenticated by WebSphere and used for access control decisions made by the WebSphere Application Server at the J2EE runtime level (such as the user identity associated with a J2EE application request and used in EJB method permission access control decisions). Operating system (OS) identity The operating system (OS) identity is the identity authenticated through the SAF interface (in the case of z/OS) and used for access control decisions made by the z/OS resource managers. Such decisions include the user identity associated with a WebSphere Application Server for z/OS servant region in a RACF STARTED class profile and used by the file system for access control decisions when the server attempts to access files.
Thread identity The thread identity is attached to a process thread executing within WebSphere Application Server. This identity can be one of the following types.
Java thread identity The Java thread identity is the J2EE identity currently associated with a Java thread managed by the WebSphere J2EE runtime (a Java thread is the Java Virtual Machine (JVM) representation of a thread). The Java thread identity is associated with a z/OS thread, but the JVM manages the user identity on the Java representation of the thread, separate from the user identity that z/OS manages on the operating system thread. The J2EE identity is current on the Java thread for the lifetime of a given application request.
Operating system (OS) thread identity The operating system identity is the identity currently associated with the operating system thread. The OS thread identity is typically the user identity assigned to the Servant region, and is normally not the same as the Java thread identity.
Note that J2EE maintains a J2EE identity that corresponds to the OS thread identity assigned to the Servant. This J2EE identity can be used as a RunAs identity when RunAs Server is specified.
RunAs identity The J2EE identity is normally the identity of the authenticated user who has made the J2EE application request. However, WebSphere Application Server allows you to force this identity to another identity as per the specification in the RunAs deployment descriptor policy on an EJB invoked within the J2EE application request.
The WebSphere Application Server RunAs policy allows three choices in assigning the Java thread identity for the current request: Assign the client (for example, user) J2EE identity - also referred to as selecting RunAs of “Caller”. Assign the server’s J2EE identity. Assign the J2EE identity that is in the specified role (J2EE roles are discussed in 9.3.2, “Using SAF for authentication and authorization - summary” on page 169).
SAF identity mapping The SWAM or LTPA authentication can be performed against a non-local user registry. The user needs to map this identity to a local user ID. In the case of WebSphere Application Server for z/OS, the local user ID is an SAF (RACF) user ID.
164 Designing for Solution-Based Security on z/OS The mapping can be achieved by using the mapping module provided with JAAS or by using a user-designed mapping module, which must then be placed in the Java Authentication and Authorization Service (JAAS) configuration.
9.2.4 WebSphere Application Server and asserted identity
A user can be authenticated by an upstream server and the asserted identity is then forwarded to WebSphere Application Server. WebSphere Application Server must validate the trustworthiness of the authenticating server.
Identity assertion with trust validation An identity assertion with trust validation can then be accomplished by using the Java Authentication and Authorization Service (JAAS) login framework, where trust validation is performed in one login module and credential creation is performed in another. These two custom login modules are used to create a JAAS login configuration that performs a login to an identity assertion.
WebSphere Application Server Trust Association Interceptor (TAI) Trust association enables the integration of IBM WebSphere Application Server security and third-party security servers. Typically, it involves a reverse proxy server that can act as a front-end authentication server while the back-end product applies its own authorization policy onto the resulting credentials that are passed by the proxy server.
The Trust Association Interface (TAI) implementation is a user-customizable interface that makes use of external authentication. It relies on another party to perform the user authentication, and it trusts this party. When it receives credentials from that party, it validates the origin and performs any required mapping.
In the setup shown in Figure 9-3 on page 165, WebSphere Application Server is used as a back-end server that further exploits its fine-grained access control.
App Server
Proof of Web Authenticator
Proof of Identity Server User Identity
Server Identity User Identity
Server Identity Proof of Session Ident 4 User Identity request User Identity User 3 1 forwarded Trusted request Proxy Server 2 •validate origin •return identity TAI
Figure 9-3 Generic Trust Association Interceptor (TAI) model
The Trusted Proxy Server proceeds with the user authentication and propagates the authenticated identity downstream to WebSphere Application Server. The WebSphere Application Server support for trust association implies that WebSphere Application Server and the Trusted Proxy Server engage in a contract in which WebSphere Application Server gives its full trust to the proxy server, and the proxy server applies its authentication policies on every request that is dispatched to WebSphere Application Server. This trust is validated by the interceptors that reside in the WebSphere Application Server environment for every
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 165 request received. The method of validation is agreed upon by the proxy server and the interceptor.
Running in trust association mode does not prohibit WebSphere Application Server from accepting requests that did not pass through the proxy server. In this case, no interceptor is needed for validating trust. It is possible, however, to configure WebSphere Application Server to strictly require that all requests go through a reverse proxy server. In this case, all requests that do not come from a proxy server will be denied immediately by WebSphere Application Server.
WebSphere Application Server 6.x ships with a TAI module known as the Trust Association Interceptor Plus (TAI++). TAI++ accepts credentials passed from TAMeb WebSEAL in the HTTP header, performs a validation against a TAM authorization server, and then creates the WebSphere Application Server PDPrincipal based on the identity that authenticated in WebSEAL. This is shown in Figure 9-4. This process allows the same identity to be used in the WebSEAL policy and in the WebSphere Application Server policy.
TAM Security Server Web Authenticator Proof of Proof of Server Identity Server Identity Java Subject Credential WebSphere Application User Identity Server Credential forwarded
request Server Identity
Credential Subject Java Credential Proof of Proof
2 4 Credential B u ild C r ed en 3 ti 1 al TAM Directory TAM GROUP-1 • validate origin USER GROUP-2 • return identity TAI
Figure 9-4 WebSphere Application Server TAI++ Implementation
It is conceivable that a WebSphere Application Server deployment could have a TAI and one or more JAAS login modules to establish different identities for the WebSphere Application Server principal.
9.2.5 Synchronize to OS thread
Some resource managers on z/OS use the OS thread identity to make authorization decisions. For example, file system access control is determined entirely based on which OS thread identity is currently on the related TCB when the file is accessed. Similarly, local Java database connectivity (JDBC™) connections to DB2 for z/OS, or file base access, use the
TCB OS thread identity as the authorization identity under certain configurations.
For these resource managers, there is therefore a need to synchronize the Operating System User Identity with the WebSphere Application Server Subject (or delegated RunAs identity) in the servlet or EJB thread so that access control is performed against the actual J2EE process identity, as opposed to the Servant region RACF user ID (which is the one most commonly used as the OS thread identity).
166 Designing for Solution-Based Security on z/OS To achieve this identity swapping, WebSphere Application Server for z/OS provides the Sync To OS Thread function. (Note that this function is considered to be quite sensitive, from a security standpoint, because the synced-to identity would be used outside of the J2EE runtime context for accessing z/OS managed resources.)
To activate the Sync To OS Thread function, the user must set all of the following items: The SAF User Registry, or a SAF Identity Mapping in effect if another registry is used. The application must include, within its deployment descriptor, an env-entry of com.ibm.websphere.security.SyncToOSThread set to true. The WebSphere Application Server Security configuration must have Sync to Thread enabled in the administrative console. The controller region must have CONTROL ACCESS to resource BBO.SYNC, if defined, in the FACILITY class (see “BBO.SYNC in the FACILITY class; BBO.SYNC in the SURROGAT class” on page 159). As an alternative, the controller region must have READ ACCESS to resource BBO.SYNC in the FACILITY class and the Servant region must have READ ACCESS to the resource BBO.SYNC.
9.3 WebSphere Application Server authorization mechanisms
WebSphere Application Server uses the J2EE authorization model. In this model, permission to invoke methods is granted to one or more “roles” during the assembly of an application. A role is a set of permissions; for example, in a banking application, roles can include teller, supervisor, clerk, and other industry-related positions.
The teller role is associated with permissions to run methods related to managing the money in an account, such as the withdraw and deposit methods. The teller role is not granted permission to close accounts; this permission is given to the supervisor role.
The application assembler defines a list of method permissions for each role, and this list is stored in the deployment descriptor for the application. The role assignment process is shown in Figure 9-5.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 167
Application Deployment Descriptor Group Æ User Mapping Resource Æ Role Mapping UserUser User User User
Role EJB Method Role Group Web URL Group User
Role Æ Principal Mapping Defined by Application Assembler Defined by Application Deployer
Figure 9-5 J2EE role assignments
WebSphere Application Server for z/OS supports three authorization mechanisms: System Authorization Facility (SAF) authorization using EJBROLE or GEJBROLE profiles in the RACF database. SAF overrides any other authorization mechanism. Tivoli Access Manager, as a Java Contract for Containers (JACC) provider. User-to-role bindings, which are created by the application assembler or the WebSphere Application Server security administrator.
Binding is the task of mapping security roles to users or groups, and it is normally performed by the system administrator when installing an application. When z/OS SAF authorization is used to check role membership, this entails having the security administrator give the required users access to the EJBROLE profiles that represent the various roles.
9.3.1 Declarative security and programmatic security
The WebSphere Application Server authorization mechanisms can be automatically invoked by the J2EE container transparently to the application (declarative security). Or, as an alternative, the J2EE application itself can perform proper authorization controls as part of its processes (programmatic security).
Declarative security Declarative security mechanisms, as part of J2EE, are stored in a document known as the deployment descriptor using declarative syntax. Global security roles for a WebSphere Application Server application are stored in the XML deployment descriptor. Security roles for WebSphere Application Server components are stored in their corresponding deployment descriptors inside the EAR, Java archives (JARs), and Web archives (WARs).
WebSphere Application Server uses method permissions to describe security roles for EJBs. For a particular EJB resource, method permissions are the association of role names with the sets of methods, based on what types of permissions should be required to invoke the methods. For example, a deployment descriptor may define a role of Teller mapped to the
168 Designing for Solution-Based Security on z/OS method getBalance of the AccountBean EJB. To access the getBalance method of AccountBean, a user must be mapped to the Teller role.
For Web resources (servlet, JSP, and URL), security constraints are the association of role names with the sets of HTTP methods, based on the types of permissions that should be required to access the resource. These are defined in the WARs deployment descriptor. For example, the user could map the role SalesPerson to the POST and GET HTTP methods in the Sales URL.
At authentication, a Subject is created for the client identity that has the information about the user and group to which the user belongs. Then the roles of the user and group are determined from the role to the user and group binding information or EJBROLE check. If the role matches with the required role for the method, access is granted. Otherwise, access is denied.
Programmatic security The use of role-based and declarative security does not require an application developer to implement security code. However, the business logic may dictate the need for different levels of security within a single EJB. For example, a method may implement a money transfer facility, but transfers over a certain amount may require additional security checks. This requires security to be implemented into the application. The API for programmatic security in J2EE consists of four methods for performing security checks: isCallerInRole (EJBContext) getCallerPrincipal (EJBContext) isUserInRole (HttpServletRequest) getUserPrincipal (HttpServletRequest)
These methods enable components to make business logic decisions based on the security role of the caller or remote user.
9.3.2 Using SAF for authentication and authorization - summary
Figure 9-6 summarizes the support provided by RACF, through the SAF interface, for WebSphere Application Server client authentication and authorization. Several conditions must be met for this to be successful, as explained here: The J2EE principals to consider are actually RACF user IDs. The RACF administrator has defined the J2EE roles planned for the deployment of the application as profiles in the EJBROLE class. The list of J2EE principals in the role is the access list of the EJBROLE profile. If a user is in the access list of an EJBROLE profile, the user has that role. If a group is in the access list of an EJBROLE profile, users in that group have that role. If the EJBROLE profile has UACC(READ), then all users have that role.
Note: When using the SAF user registry, WebSphere Application Server recognizes the membership of users to groups according to the users-to-groups connections in RACF.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 169
Request 1 http/https 4 Web / EJB Container RMI/IIOP Servlet execution or EJB RunAs other principal beans is principal in role ? declarative or programmatic Authentication/ 2 Mapping 3 Authorization to Role SAF
USER profile ejbrole profile access list APPLDATA=role_surrogate
RACF userID becomes the Java Principal Figure 9-6 RACF support for J2EE authentication and authorization
The sequence of events, as depicted by the numbers in the figure, is explained here: 1. The J2EE client sends a request to WebSphere Application Server for z/OS. 2. The caller authenticates by means supported by WebSphere Application Server JAAS login modules and RACF. These means are basic authentication with user ID and password or PassTicket, or digital certificate with RACF identity mapping. After it is successfully authenticated, and mapped (if required), the RACF user ID becomes the authenticated JAAS principal. The JAAS Subject also contains the groups that the principal belongs to. 3. To check whether the Principal is in the right role, WebSphere Application Server sends a request for verifying permission of the JAAS Principal (RACF user ID) to the EJBROLE profile. 4. The RunAs identity is assigned, according to the deployment descriptor, to the J2EE thread, with the ability to assign a default identity for a given role.
WebSphere Application Server supports a form of delegation where a user Identity can be represented as a J2EE role. For example, an application can be established to run with RunAs Role of roleX, as specified in its deployment descriptor, and WebSphere Application Server is also instructed to map a specific Principal to roleX. With RACF support for the J2EE roles, the Principal (that is, the RACF user ID) to be mapped to a role is specified in the APPLDATA field of the EJBROLE profile defined for this role.
For example, the administrator would use the following statement using the RACF command RDEFINE, where
RDEFINE EJBROLE roleX UACC(NONE) APPLDATA(
9.3.3 Using Java Authorization Contract for Containers (JACC) for authorization
The Java Authorization Contract for Containers (JACC) was introduced in J2EE to allow third-party authorization service providers to plug into application servers like WebSphere Application Server using standard interfaces for policy configuration and access decisions. It
170 Designing for Solution-Based Security on z/OS describes a standard contract (interfaces and rules) that authorization framework providers must meet. Figure 9-7 shows the relationships between the J2EE Container and the JACC Provider.
J2EE Container Application Management Application Access Enforcement User Admin (deploy, undeploy)
Manage resources, Access Allowed? roles, mappings
Policy Configuration Access Decision
JACC Provider
Provider Repository
Figure 9-7 Java Authorization Contract for Containers (JACC)
WebSphere Application Server Version 6 ships with a JACC Provider that uses the Tivoli Access Manager (TAM) authorization framework (that is, the aznAPI and TAM access control database) for the container-level J2EE role-based authorization.
The J2EE roles, resources, and mappings as defined in the application descriptors are implemented in TAM when the application is installed. The users and groups can be administered using either TAM utilities or through the WebSphere Application Server administration console. However, principal-to-role mapping is only performed through the WebSphere Application Server administrative console.
A Tivoli Access Manager security utility is embedded within WebSphere Application Server Version 6 and is used to: Add security policy information into the TAM access control database when applications are deployed When an application is deployed in WebSphere Application Server, Tivoli Access Manager gathers the security information from the application and integrates it into the Tivoli Access Manager space. Tivoli Access Manager creates objects, ACLs, servers, users, and groups during the deployment of such applications. This allows fine-grained access control for these objects. Authorize access to WebSphere Application Server-secured resources Any time a client tries to access a resource in the application, WebSphere Application Server directs the security decisions to Tivoli Access Manager.
Note that the J2EE authorization policy is implemented in the same policy database as the other TAM access enforcement points in the TAM domain. The same users and groups can be mapped both to the policy dedicated to WebSeal access controls and to the J2EE roles, by having their access controlled both to the WebSphere Application Server URL and to the J2EE resources.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 171 WebSphere Application Server with the TAM JACC Provider architecture The components involved with the TAM JACC Provider in WebSphere Application Server are shown in Figure 9-8. This figure extends the generic JACC design illustrated in Figure 9-7.
WebSphere 6.x
Application Application Management Access Enforcement Admin (deploy, undeploy) User
Policy Configuration Access Decision
TAM Policy Replicated TAM TAM Server Server Policy Db
TAM JACC Provider – shipped with WebSphere Application Server 6.x
AM Java Runtime – shipped with WebSphere Application Server 6.x TAM Auth TAMServer(s) Auth Server(s) Master TAM Policy Db
Figure 9-8 WebSphere Application Server and Tivoli Access Manager JACC Provider
This implementation includes: The TAM JACC Provider. This is shipped with WebSphere Application Server Version 6, and implemented as a series of Java classes. It includes an embedded TAM client that will hold a local copy of the TAM policy database. The local copy of the TAM policy database will be replicated by the TAM policy server in the same way as for WebSEAL and other TAM clients. The TAM Java Runtime (TAMJrte) libraries. These enable communication between TAM components, such as the TAM policy server and TAM authorization servers. Remote TAM authorization servers (one or more). The TAM policy server and master policy database.
The TAM JACC Provider also adds a JAAS login module to verify the TAM credentials. This module uses the remote authorization servers to build the PdPrincipal.
The TAM JACC Provider implementation requires users to authenticate to WebSphere Application Server with a TAM identity. This can occur via user authentication directly against WebSphere Application Server. However, it is more likely to be via WebSEAL SSO. With WebSEAL SSO, a user authenticates to WebSEAL and the WebSEAL credentials are passed to the TAI++ module to build the WebSphere Application Server credentials, as shown in Figure 9-4 on page 166.
9.4 Using LDAP as a user registry for WebSphere Application Server
Chapter 6, “Using the LDAP directory as a User Registry” on page 91, explains how user entities can be specified in an LDAP directory so that applications can use the directory for user authentication and the collection of group membership.
172 Designing for Solution-Based Security on z/OS WebSphere Application Server supports using an LDAP directory-based user registry as an alternative to a local operating system (in our case, RACF) or Custom User Registry. The specific way WebSphere Application Server is to behave as an LDAP client, when it comes to binding and authenticating users, is dictated both by the type of LDAP server (and implicitly, the supported schemas) and how (that is, using which attribute) the user entries will be located in the directory.
Therefore, WebSphere Application Server comes with a default set of LDAP filters, out of which the administrator selects the filter to use when performing the LDAP search for the user LDAP entry. (Provision is also made so that the administrator can specify custom filters.)
The administrator should also specify in WebSphere Application Server the distinguished name and password to use to bind to the LDAP user registry (if anonymous bind is not permitted), as well as the base distinguished name to use (that is, the entry in the directory to start searching from).
In the following sections we describe the LDAP search filters that are used by WebSphere Application Server.
User filter This filter specifies the LDAP filter to use for searching the user registry for an entry corresponding to a user. As an example, WebSphere Application Server can be set up to search the LDAP directory for a uid attribute value, in an inetOrgPerson object class entry, that matches the identity entered by the user.
Group filter This filter specifies the LDAP filter to use for searching the user registry for a specific group of users. As an example, WebSphere Application Server can be set up to search the LDAP directory for a cn attribute value that matches a group common name, when found in a groupOfNames or groupOfUniqueNames object class entry.
User ID map This filter retrieves a specific attribute value from the LDAP user entries. It can be used when executing the getCallerPrincipal or getUserPrincipal method to obtain the user identity corresponding to an authenticated distinguished name. Typically, WebSphere Application Server can be set up to retrieve the uid attribute values in all occurrences of the inetOrgPerson object class, along with the distinguished name of the entries where the occurrences have been found.
Group ID map This filter retrieves a specific attribute value from the LDAP group entries. Typically, WebSphere Application Server can be set up to retrieve a list of the cn values found in group entries.
Group member ID map This filter queries all groups that match the specified object classes to see if the user identity is contained in the specified attributes. As an example, WebSphere Application Server can be set up to retrieve a specific member attribute value among the entries that contain the groupOfNames object class.
Certificate map mode This filter maps attributes in the client certificate to user entries in the LDAP registry. Typically, WebSphere Application Server can be set up to retrieve directly the entry designated by the subject’s distinguished name in the certificate. Alternatively, it can, for example, search the
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 173 entries that contain the inetOrgPerson object class with a uid attribute value that matches the subject’s common name in the certificate.
9.4.1 Using z/OS LDAP as a user registry
The integrated security Services LDAP server or the newer IBM Tivoli Directory Server (ITDS) for z/OS can be used as a WebSphere Application Server LDAP user registry. The commonly used schemas that these search filters are based on are provided with all z/OS LDAP servers. The z/OS LDAP Native Authentication feature can also be used for any bind with basic authentication.
9.4.2 Using LDAP authentication and RACF authorization
Users must configure a pluggable mapping module if LDAP is the user registry and they want to use System Authorization Facility (SAF) services such as: System Authorization Facility (SAF) EJBROLE profiles, to control WebSphere Application Server authorization Enabling an application to sync to OS thread (see 9.2.5, “Synchronize to OS thread” on page 166) Auditing, using SMF audit
Note: For the tests we conducted while writing this book, we used a simple module that is available at the Info Center: com.ibm.websphere.security.SampleSAFMappingModule.
The pluggable mapping module must provide the following information: com.ibm.wsspi.security.token.AttributeNameConstants.ZOS_USERID This attribute is used to set the value of the z/OS user ID when an operation is performed that requires a z/OS SAF user ID. If a value is not specified, then WebSphere Application Server uses the unauthenticated user to establish a SAF user ID. This SAF user ID must be a valid z/OS user ID. com.ibm.wsspi.security.token.AttributeNameConstants.ZOS_AUDIT_STRNG This attribute is used to indicate that the specified string is placed in the X500Name property when creating a RACF access control environment element (ACEE). The attribute associates an audit string with a SAF user, which is displayed in the System Management Facility (SMF) record. com.ibm.wsspi.security.token.AttributeName.Constants.CALLER_PRINCIPAL_CLASS Use this optional field to indicate which Principal class in a JAAS subject is returned when using the getCallerPrincipal and getUserPrincipal APIs.
The module must be added to each of the following system login module configurations, and also must be positioned at the second-to-last position in the system login modules ordered list in the configurations: WEB_INBOUND RMI_BOUND DEFAULT login modules
174 Designing for Solution-Based Security on z/OS 9.4.3 Using z/OS LDAP as an authorization database
The IBM RACF Remote Authorization Provider (IBMRRAP) extends RACF authorization and audit functions that are available to applications and containers on z/OS to WebSphere Application Server containers running on distributed systems. IBMRRAP is a set of classes that exploit both the JACC feature of the WebSphere Application Server V6 container on any platform (see JACC in 9.3.3, “Using Java Authorization Contract for Containers (JACC) for authorization” on page 170), and the Remote Authorization and Auditing Services that z/OS RACF can provide (beginning with z/OS V1R8) when the z/OS instance hosts the ITDS for a z/OS LDAP server.
The RACF Remote Authorization Service is described in 4.5.4, “RACF remote services at z/OS V1R8” on page 64. This service allows an application that is external to the z/OS system hosting the RACF instance, to invoke RACF, via the LDAP protocol, in order to verify whether a user of the remote application is permitted to a RACF-protected resource.
When the WebSphere Application Server container is presented with a request for a resource, the resource name and any available authentication information is processed by IBMRRAP and sent via LDAP to RACF. It is expected that the authorization requests issued by IBMRRAP pertain to resources in the RACF EJBROLE class of resources, and are intended to determine whether the local JAAS Principal in WebSphere Application Server is in the right role to access the local J2EE resource.
Important: IBMRRAP only provides for authorization for J2EE applications roles. It does not support obtaining authorization for the WebSphere Application Server administrative roles.
In addition to authorizing users to resources, IBMRRAP provides an end-to-end audit record, because whenever the IBMRRAP system is invoking the remote authorization service, it also provides auditing information via the remote auditing service. See 9.6.2, “Security auditing service” on page 189 for more information about this topic.
There are two main design points associated with the development of IBMRRAP: The positioning of IBMRRAP as an authorization engine in WebSphere does not require that the WebSphere administration be changed, so the application deployment does not require any z/OS skill. There is no additional RACF administration skill required on the RACF side, either, because resources are defined and users and groups are granted access using standard RACF procedures.
IBMRRAP is available as an “as is” download provided by IBM at: http://www-03.ibm.com/systems/z/os/zos/downloads/#asis
9.5 Web Services security overview
One of the key requirements for the security model in today’s business environment is the ability to interoperate between formerly incompatible security technologies (such as public key infrastructure, Kerberos and so on) in heterogeneous environments (such as Microsoft.NET and J2EE).
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 175 Web Services security for WebSphere Application Server is based on standards included in the Organization for the Advancement of Structured Information Standards (OASIS) Web Services Security (WSS) Version 1.0 specification, the Username token Version 1.0 profile, and the X.509 token Version 1.0 profile.
Web Services Security is a message-level standard based on securing SOAP messages through XML digital signature, securing confidentiality through XML encryption, and securing credential propagation through security tokens. A typical example of the security token is a username token, in which a user name and password are included as text in the message header. Web Services Security defines how to encode binary security tokens using methods such as X.509 certificates and Kerberos tickets.
Web service security is supported in the WebSphere Application Server-managed Web service container.
9.5.1 High level architecture for Web Services Security
WebSphere Application Server Version 6 and later use the Java 2 Platform, Enterprise Edition (J2EE) Version 1.4 Web services deployment model to implement Web Services Security. One of the benefits of this deployment model is that the user can define the Web Services Security requirements outside of the application business logic. With the separation of roles, the application developer can focus on the business logic and the security expert can specify the security requirement.
The Web Services Security constraints are specified in the IBM extension of the Web services deployment descriptors and bindings. The Web Services Security runtime enforces the security constraints specified in the deployment descriptors.
Figure 9-9 illustrates the high level architecture model that is used to secure Web services in WebSphere Application Server Version 6.
Client Server
WSS Runtime WSS Runtime
Request Request Generator Consumer
Response Response Consumer Generator
Client Deployment Descriptor Server Deployment Descriptor
Request Generator Configuration Request Consumer Configuration
Response Consumer Configuration Response Generator Configuration
Client Binding configuration Server Binding configuration Request Generator Configuration Request Consumer Configuration
Response Consumer Configuration Response Generator Configuration
Figure 9-9 Web Services high level architecture model
176 Designing for Solution-Based Security on z/OS The deployment descriptor and binding for Web Services Security is based on Web service ports. Each Web service port, as specified in the Web Services Description Language (WSDL), can have its own unique Web Services Security constraints defined. For example, you might configure Web service port A to sign the SOAP body and the Username token. You might configure Web service port B to encrypt the SOAP body content, and so on.
As shown in Figure 9-9, there are two sets of configurations on both the client side and the server side (request generator/request consumer and response generator/response consumer), as explained here.
Request generator This client-side configuration defines the Web Services Security requirements for the outgoing SOAP message request. These requirements might involve generating a SOAP message request that uses a digital signature, incorporates encryption, and attaches security tokens.
Request consumer This server-side configuration defines the Web Services Security requirements for the incoming SOAP message request. These requirements might involve verifying that the required integrity parts are digitally signed; verifying the digital signature; verifying that the required confidential parts were encrypted by the request generator; decrypting the required confidential parts; validating the security tokens, and verifying that the security context is set up with the appropriate identity.
Response generator This server-side configuration defines the Web Services Security requirements for the outgoing SOAP message response. These requirements might involve generating the SOAP message response with Web Services Security including digital signature, and encrypting and attaching the security tokens, if necessary.
Response consumer This client-side configuration defines the Web Services Security requirements for the incoming SOAP response. The requirements might involve verifying that the integrity parts are signed and the signature is verified; verifying that the required confidential parts are encrypted and that the parts are decrypted; and validating the security tokens.
Important: The JAX-RPC Web services implementation is used in WebSphere Application Server. However, the newer JAX-WS model is being implemented (as the optional Feature Pack, on top of WebSphere Application Server 6.1) and is now the IBM strategic programming model.
Most of the more recently implemented specifications (such as WSS 1.1, WS-SecureConversation (with WS-Trust), API support, Policy Set and so on) are implemented with the JAX-WS Java programming model for Web services. Therefore, we strongly recommend that WebSphere Application Server Web services users use the JAX-WS model for development.
JAX-WS model overview The high level architecture of the Web Service Security runtime is shown in Figure 9-10. The programming model could be using API (only on the client side, because API is not supported on the provider side) or Policy Set. The SOAP message is secured, based on the requirements from the API or Policy Set. Business application messages and out-of-band messages are also secured, using the same mechanism.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 177 The pluggable token framework is simplified, because both token generation and validation (authentication) are using the same programming model, and they are JAAS-based. The new SecurityToken interface is also introduced. The Token Generator, Token Consumer, and KeyLocator proprietary interfaces are not used anymore.
The new design allows custom development to be used for both API and Policy Set.
Policy Set Policy Set
Request Generator Consumer JAX-WS Client invokes invokes JAX-WS (or using Service WS API) Response Consumer Generator Requestor Provider
Pluggable Pluggable Token Framework JAAS LoginModule JAAS LoginModule Token Framework
SecurityToken JAAS CallbackHandler SecurityToken JAAS CallbackHandler
Figure 9-10 The JAX-WS model
Security model mixture There can be multiple protocols and channels in the WebSphere Application Server Version 6 and later programming environments. Each of these applications serve different business needs.
For example, users might access: A Web-based application through the HTTP transport such as a servlet, JavaServer Pages (JSP) file, HTML and so on. An enterprise application through the Remote Method Invocation (RMI) over the Internet Inter-ORB (RMI/IIOP) protocol. A Web service application through the SOAP over HTTP, SOAP over the Java Message Service (JMS), or SOAP over the RMI/IIOP protocol.
More importantly, Web services are often implemented as servlets with an Enterprise JavaBeans (EJB) file, or even servlets alone. Therefore, users can mix and match the Web Services Security model with the J2EE security model for Web and EJB components. It is intended that Web service security team with the J2EE role-based security and the security runtime for WebSphere Application Server Version 6 and later.
Web Services Security also can take advantage of the security features in J2EE and the security runtime for WebSphere Application Server Version 6 and later. For example, Web Services Security can use the following security features to provide an end-to-end security deployment:
178 Designing for Solution-Based Security on z/OS Use the local operating system, Lightweight Directory Access Protocol (LDAP), and custom user registries for authenticating the username token Propagate the Lightweight Third Party Authentication (LTPA) security token in the SOAP message Use identity assertion Use a trust association interceptor (TAI) Enable security attribute propagation Use J2EE role-based authorization Use a Java Authorization Contract for Containers (JACC) authorization provider, such as Tivoli Access Manager
Figure 9-11 shows that different security protocols are used to send authentication information to the application server. For a Web service, the user might use either HTTP basic authentication with SSL/TLS or a Web Services Security username token with encryption.
Note: Be aware that the protection provided by the SSL/TLS protocol ends at the SSL/TLS client and server endpoints (the data flows in the clear within the client or the server programs).
In contrast, message-level protection by encryption is preserved across servers, until a message consumer is given the capability of decrypting the message. In that sense, message-level encryption provides end-to-end security.
In Figure 9-11 on page 179, when identity “bob” from Web Services Security is authenticated and set as the caller identity of the SOAP message request, the J2EE Enterprise JavaBeans container performs authorization using bob before the call is dispatched to the service implementation, which in this case is the enterprise bean.
bob http://www.fabrikam456.com/travelServices
SOAP/HTTP SOAP authentication wsse:UsernameToken Runtime based on
HTTP request authentication by HTTP end point based on HTTP joe J2EE joe HTTP BasicAuth: BasicAuth bob Container
authentication by ORB EJB CSIv2 protocol: based on CSIv2
Alice
Figure 9-11 Web Services transport and message authentication
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 179 Note that transport layer security, such as SSL or TLS, provides point-to-point security only. This layer of security might be adequate for certain scenarios. However, when the SOAP message must travel through intermediary servers (multi-hop) before it is consumed by the target endpoint, you might want to use SOAP over the Java Message Service (JMS).
The usage scenarios and security requirements dictate how to secure Web services. The requirements depend upon operating environment and business needs. However, a key benefit of using Web Services Security is that it is transport layer-independent; that is, the same Web Services Security constraints can be used for SOAP over HTTP, SOAP over JMS, or SOAP over RMI/IIOP.
9.5.2 Web Services Security for SOAP Message V1.0 feature overview
The Web Services Security for SOAP Message Version 1.0 specification is designed to be flexible and accommodate the requirements of Web services. For example, Web Services Security Version 1.0 does not define a mandatory security token. Instead, it defines a generic mechanism for associating the security token with an SOAP message.
The use of security tokens is defined in the various security token profiles, such as: The username token profile The X.509 token profile The Security Assertion Markup Language (SAML) token profile
WebSphere Application Server Version 6 and later include the following key enhancements: Support for the client (sender or generator) to send multiple security tokens in a SOAP message. Ability to derive keys from a security token for digital signature (verification) and encryption (decryption). Support to sign or encrypt any element in an SOAP message. However, some limitations exist. For example, encrypting some parts of a message might break the SOAP message format. If you encrypt the SOAP body element, the SOAP message format breaks. Support for signing the SOAP envelope, the SOAP header, and the Web Services Security header. Ability to configure the order of the digital signature and encryption. Support for various mechanisms to reference the security tokens such as direct references, key identifiers, key names, and embedded references. Support for the PKCS#7 format certificate revocation list (CRL) encoding for an X.509 security token. Support for CRL verification. Ability to insert nonce and time stamps into elements within the Web Services Security header, into signed elements, or into encrypted elements (this is a WebSphere Application Server extension). Support for identity assertion using the Run As (invocation) identity in the current security context for WebSphere Application Server. Support for a default binding, which is a set of default Web Services Security bindings for applications. Support for the acceleration of hardware cryptographic devices. Support for secure keys. Support for the Basic Security Profile (WS-I BSP 1.0).
180 Designing for Solution-Based Security on z/OS Non-OASIS activities - specifications IBM and Microsoft jointly published a security white paper on Web services entitled “Security in a Web Services World: A Proposed Architecture and Roadmap”. The white paper discusses the following initial and subsequent specifications in the proposed Web Services Security roadmap. Web service security This specification defines how to attach a digital signature, use encryption, and use security tokens in SOAP messages. Find it at: http://www.ibm.com/developerworks/library/specification/ws-secmap
WS-SecurityPolicy This specification defines the language that is used to describe security constraints and the policy of intermediaries or endpoints.
WS-Trust This specification defines a framework for trust models to establish trust between Web services.
WS-Privacy This specification defines a model of how to express a privacy policy for a Web service and a requester.
WS-SecureConversation This specification defines how to exchange and establish a secured context that derives session keys between Web services.
WS-Federation This specification defines a model for trust relationships in a heterogeneous, federated environment, including federated identities management.
WS-Authorization This specification defines the authorization policy for a Web service. However, the WS-Authorization specification has not been published as of the time of writing.
Practical implementation of authorization with Web services: Today, when developing a Web service that requires method-level authorization checks, the user must use stateless session beans to implement the Web service. When developing a Web service that is implemented as a servlet, a user can use coarse-grained or URL-based authorization in the Web container. However, in this situation, users cannot use the identity from Web Services Security for authorization checks. Instead, the identity from the transport can be used (that is, when transporting SOAP over HTTP, the identity that is in the HTTP transport can be used). Custom Authorization can still be performed by the J2EE container through the JACC interface.
Figure 9-12 shows the relationship between these specifications.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 181
WS-Secure WS- WS-Federation Conversation Authorization
WS-Security Policy WS-Trust WS-Privacy
WS-Security Foundation
Web Service SAML Token Profile SOAP With Security Attachments
Username Token X.509 Token Profile Kerberos Token Profile Profile
REL Token Profile Standards
XML Digital Signature XML Encryption Specifications published
SOAP Foundation Specifications not published yet
Figure 9-12 Web services specifications
9.5.3 Using identity assertion with Web services
In a secured environment such as an intranet, an SSL/TLS connection, or a Virtual Private Network (VPN), it is acceptable and often useful to send the requester identity only, without any requester’s credential (such as a password), as long as the sending party provides its own trusted credential such as its server’s identity.
WebSphere Application Server Version 6 and later support the following types of asserted identities: A username token without a password An X.509 token for an X.509 certificate
For the X.509 certificate, WebSphere Application Server uses the distinguished name in the certificate as a requester identity.
There are two trust modes for validating the trust of the upstream server: basic authentication and signature, as explained here:
Basic authentication (username token) In this authentication mode, the upstream server sends a username token with a user name and password to a downstream server. The consumer or receiver of the message authenticates the username token and validates the trust based upon the TrustedIDEvaluator implementation. The TrustedIDEvaluator implementation must implement the Java interface com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator.
Signature In this authentication mode, the upstream server signs the message, which can be any message part such as the SOAP body. The upstream server sends the X.509 token to a downstream server. The consumer or receiver of the message verifies the signature and validates the X.509 token. The identity or the distinguished name from the X.509 token that is used in the digital signature is validated based on the TrustedIDEvaluator implementation. The TrustedIDEvaluator implementation must implement the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator Java interface.
182 Designing for Solution-Based Security on z/OS Figure 9-13 depicts the identity assertion trust process.
JAAS Login Trusted ID Configuration Evaluator
xxx/pwd xxx
Server s2 Server s1 Identity (username token): bob Trust mode (username token): xxx/pwd Request Request bob Generator Secured SOAP message Consumer Downstream call Response Response Consumer Secured SOAP message Generator
WSS Runtime WSS Runtime
Figure 9-13 Web services identity assertion trust process
In Figure 9-13, server s1 is the upstream server and identity assertion is set up between server s1 and server s2. The s1 server authenticates the identity known as “bob”.
Server s1 wants to send bob to the s2 server with a password. The trust mode is an s1 credential that contains the identity and a password. Server s2 receives the request, authenticates the user using a Java Authentication and Authorization Service (JAAS) login module, and uses the trusted ID evaluator to determine whether to trust the identity.
If the identity is trusted, bob is used as the caller that invokes the service. If authorization is required, bob is the identity that is used for authorization verification.
In WebSphere Application Server Version 6 and later, the identity can be asserted as the RunAs (invocation) identity of the current security context. For example, the Web services gateway authenticates a requester using a secure method such as password authentication, and then sends the requester identity only to a back-end server. You could also use identity assertion for interoperability with another Web Services Security implementation.
9.5.4 Web Services Security implementation in z/OS overview
This section provides an overview of the functional areas in WebSphere Application Server and z/OS that participate in the implementation of Web Services Security, with a focus on the features that are unique to z/OS.
Figure 9-14 is a high level representation of the components and functions involved in the form of functional layers described here.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 183
WebSphere Application Server – Web Services runtime WS-Security
WebSphere Application Server Container
JAAS Configurations: JAAS, LTPA, SSL, providers, …
User Registry Java Crypto Java Support Roles APIs Certificates keystore/truststore IBMJSSE2 JVM z/OS IBMJCECCA IBMCertPath
RACF User registry ICSF Access control DB
Hdw Crypto keyrings CDKS PKDS
HDW Crypto Support
z/OS Network Security
Figure 9-14 z/OS components and functions involved in Web Services Security
z/OS Network security layer This layer refers to the security mechanisms imbedded in the z/OS Communications Server. They are described in further details in Chapter 8, “Overview of TCP/IP network security” on page 123. Web services runtime layer This layer implements WebSphere security, and that invokes the relevant lower-level services and mechanisms in the WebSphere Application Server and z/OS layers whenever necessary. WebSphere Application Server container The container acts as a security services provider for the Web services runtime layer for the HTTP transport level and J2EE role-based security. For instance, SOAP message authentication is performed via the JAAS login configuration in use in WebSphere Application Server. Likewise, the transport level protection with SSL/TLS is achieved by the WebSphere Application Server container. Java support in z/OS Although the Java security model is implemented and performed in the JVM runtime, calls to cryptographic services can be handled by specific classes that drive the request to the z/OS integrated hardware cryptography support. RACF user registry and roles database, and RACF key rings These elements are an implementation of the z/OS security mode, but are exploited in the context of Web Services Security on z/OS. The description provided in 9.3.2, “Using SAF for authentication and authorization - summary” on page 169, which explains how RACF
184 Designing for Solution-Based Security on z/OS can be used as a WebSphere Application Server user registry and authorization database, still applies in the context of Web Services security. RSA and DSA keys that are kept in the RACF database key rings can also be used in the context of transport-level security or message-level signature. For RSA keys, they can be provided to the System z hardware cryptographic coprocessors so that the required computations are run by hardware instead of software. Hardware cryptography support A general description of z/OS hardware cryptography support is provided in Chapter 5, “A brief reminder about System z integrated hardware cryptography” on page 79. Figure 9-15 focuses on the hardware support for Java cryptography. The figure shows the IBM cryptographic provider classes that you can select for WebSphere Application Server: IBMJCECCA for the base cryptographic services, and IBMJSSE2 for SSL/TLS support. Executing these classes results in calling ICSF, or directly invoking the CPACF facility, for services that can be performed by the hardware. Because the Java code in WebSphere Application Server container relies on the Java key store concept to manage keys and keys repositories, the IBMJCECCA provider gives a key store representation for the z/OS cryptographic key repositories, as explained here: – z/OS UNIX files appear as key stores of the JCEKS type. – The ICSF PKDS VSAM dataset appears as a JCECCAKS key store type. – z/OS offers the capability of keeping RSA keys connected to a RACF key ring residing in the ICSF PKDS. Java users should then refer to a JCECCARACFKS key store. – Or RSA keys can be kept in the RACF database; then the key store type is JCERACFKS.
WebSphere Application Server Java Container «keystores»
API API
JSSE Provider HFS (IBMJSSE2) file JVM JCE Provider (IBMJCECCA) RACF keyrings
•Digital Signatures via RSA •One-way: SHA1, SHA256, MD2, MD5 PKDS •Symmetric Algorithms -- DES, 3DES, AES128 ICSF •Asymmetric Algorithms – RSA •Random number generation
Supported keystores Master Key CPACF JCEKS (file based) •JCECCAKS (PKDS) CEX2C •JCECCARACFKS (RACF with PKDS) •JCERACFKS (RACF/SAF) Figure 9-15 z/OS integrated hardware cryptography exploitation
Note that WebSphere security can also leverage the hardware cryptography support on z/OS through the IBMJCECCA provider.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 185 9.5.5 Security threats specific to XML SOAP messaging
With a Web services implementation, SOAP messages should not be considered user interfaces. Rather, they are part of the business logic and, from the perspective of security exposures, they require specific attention. There are threats related to the use of XML messaging that the usual security devices, such as firewalls, cannot apprehend because these threats stem from the contents of the message and the way they are exploited by their consumers. Examples of identified threats today are classified in four broad categories: XML Denial of Service (xDOS) As with any other technology denial of service attack, the xDOS goal is to slow down or disable a Web service so that valid service requests are hampered or denied. Beyond the pure multiple-messages kind of denial-of-service attack, XML can experience more specific xDOS attacks such as: – Jumbo Payloads, which are very large XML messages intended to overly consume memory and CPU time on the target system – Recursive Elements, which involves sending XML messages that can be used to force recursive entity expansion or other repeated processing that, again, overly consumes CPU time – Public Key denial of service, where messages include high numbers of digital signatures using very long key lengths, forcing the recipient to dedicate a large amount of computing resource to the verification of these digital signatures Unauthorized access This refers to gaining unauthorized access to a Web service or its data, and entails classical dictionary attacks to attempt guessing a user password, modified messages, or replayed messages. Data integrity or confidentiality compromise These attacks aim at affecting the data integrity of Web service responses, requests, or underlying databases, or at collecting data exploitable for a cryptanalysis of the messages. Examples of such attacks include: – SQL Injection; that is, modifying SQL statements in the XML message to obtain more data than the service is designed to return. – Web Services Description Language (WSDL) enumeration analysis, to guess and gain access to unlisted services – Routing Detour, which uses the SOAP routing header to access internal Web services System compromise This involves corrupting the Web service itself or the servers that host it by using techniques such as: – Malicious Include, which causes a Web service to include invalid external data in output or return sensitive files from the server file system, which could be achieved by using URLs from embedded files
– XML encapsulation, which involves embedding system commands in the XML payload, for example through the CDATA tag
Current firewall devices operate at the transport level. Some may act at a higher level, inspecting the data payloads of IP packets. However, today it takes specific devices to conduct a proper inspection of XML messages and make decisions based on the content and structure of these messages.
186 Designing for Solution-Based Security on z/OS
Important: Many of these threats can be mitigated in WebSphere Application Server with a proper security setup, as described in Application Server for z/OS, Securing Applications
and Their Environment, SA22-7961.
Enterprises can also consider enhancing their security infrastructure with specialized appliances, as discussed next.
The IBM DataPower® XS40 XML Security Gateway has been designed to help protect against these XML attacks and others. It can be thought as a complement to traditional firewall devices when carrying XML SOAP messaging over TCP/IP protocols. Figure 9-16 illustrates the positioning of the IBM DataPower XS40 with respect to traditional firewall devices.
SOAP request
XML Firewall Server IP Firewall Figure 9-16 Positioning the IBM DataPower XS40 XML Security Gateway
IBM DataPower SOA appliances are discussed in the following ITSO Redpaper publications: REDP-4327, REDP-4365, REDP-4364 and REDP-4366.
9.6 WebSphere Application Server and auditing
Today, WebSphere Application Server on any platform issues its own auditing information, which appears as messages in the miscellaneous log files managed by WebSphere Application Server. A more structured auditing approach, known as the auditing service, was added in WebSphere Application Server Version 7. It enables WebSphere Application Server to generate security auditing records for certain security events.
9.6.1 Auditing capabilities for WebSphere Application Server for z/OS
This section highlights the collections of security audit-oriented information that user activities in a WebSphere Application Server for z/OS instance can generate.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 187 WebSphere Application Server for z/OS fully supports the auditing service provided WebSphere Application Server V7. Further information about the auditing service is provided in 9.6.2, “Security auditing service” on page 189. If access to the WebSphere Application Server URL is protected by a security proxy such as Tivoli Access Manager with WebSEAL, then TAM also issues its own auditing data that specific programs have to exploit. When RACF is used as a user registry, WebSphere Application Server indirectly triggers the issuance of SMF data, and authentication attempts are recorded in SMF type 80 records. When RACF is used as the WebSphere Application Server authorization database, and holds the permissions to the EJBROLE resources, SMF records can be generated that contain permission-checking results.
Note: WebSphere Application Server does not exploit the syslog daemon facility.
WebSphere Application Server authorization auditing with RACF The JAAS Principal is retrieved in the RACF SMF auditing information when either one of the following actions is performed: EJBROLE authorization check Any access check for an application that is running with the operating system identity and synchronized to the J2EE identity (as a result of the SyncToOSThread function explained in 9.2.5, “Synchronize to OS thread” on page 166)
WebSphere Application Server for z/OS uses the SAF RACROUTE AUTH and RACROUTE FASTAUTH operations and passes the LOG option that is specified in the security configuration.
The options are DEFAULT, ASIS, NOFAIL, and NONE, as explained here: DEFAULT When multiple role constraints are specified (such as, a user must be in one of a set of roles) then all of the roles except for the last role is checked with the NOFAIL option. If the authorization is granted in one of the roles before the last role, WebSphere Application Server writes an authorization success record. If the authorization is not successful in these roles, the last role is checked with the ASIS log option. If the user is authorized to the last role, a success record might be written. If the user is not authorized, a failure record might be written. ASIS This specifies that the audit events are recorded in the manner that is specified in the profile that protects the resource, or in the manner that is specified by the SETROPTS options. NOFAIL This specifies that failures are not recorded. Authorization failure messages are not issued, but successful authorization audit records might be written.
NONE This specifies that successes are not recorded and failures are not recorded.
Only one authorization failed record is written for a failed J2EE authorization check, even if several SAF authorization calls are made.
188 Designing for Solution-Based Security on z/OS 9.6.2 Security auditing service
The WebSphere Application Server security auditing service, provided in WebSphere Application Server Version 7, provides a programmatic interface to other WebSphere security components to generate security auditing event records. Security auditing has the following key features: A mechanism designed to capture and log authentication, authorization, system management, security and audit policy management type events Archiving rules that may be provided by consumers Plug Point interfaces designed to allow recording of events to some third party Enterprise Auditing Management Facility
It is designed to support auditing a variety of events such as: Authentication Authorization Principal/Credential mapping Key management Security policy management Audit policy management User registry and Identity management Logouts Delegation Resource access Signing and encryption Admin Configuration Management Admin Runtime Management
Audit data can go into a flat Audit File owned by WebSphere Application Server, and optionally be configured to be tamper-proof by using signing and encryption. The audit data can also be directed to SMF Type 83 subtype 5 records.
9.6.3 Remote Authorization requests performed via IBMRRAP
When an authorization request is sent to z/OS by IBMRRAP, RACF will automatically log an SMF type 80 record for the authorization check, depending on the audit settings defined for the class or resource.
IBMRRAP will also asynchronously send a Remote Audit request to ITDS, which results in an SMF type 83, subtype 4 record being generated. This is required because IBMRRAP may get the authorization information from a local cache of recent authorization requests responses, to save on RACF remote accesses. For consistency, all authorization requests are logged via the Remote Audit service, whether satisfied by a request to ITDS, or by the cache.
Note the following points: Authorization requests satisfied by requests to ITDS will have both an SMF type 80 record and an SMF type 83, subtype 4 record created, if the resource profiles are set to require auditing. Authorization requests satisfied by the cache will only have an SMF type 83 record created.
Chapter 9. WebSphere Application Server for z/OS and Web Services Security basics 189
190 Designing for Solution-Based Security on z/OS
10
Chapter 10. Tivoli products that team with the mainframe
In this chapter we provide a very high level description of Tivoli security products that can team with mainframe security technologies to complement or extend their reach and satisfy the new requirements of the On Demand environment.
The following products are discussed: IBM Tivoli Federated Identity Manager (TFIM) IBM Tivoli Security Operations Manager (TSOM) and IBM Tivoli Security Compliance Manager IBM Tivoli zSecure suite IBM Tivoli Access Manager (TAM) BM Tivoli Identity Manager (TIM) IBM Tivoli Directory Server (ITDS) IBM Tivoli Directory Integrator (ITDI)
© Copyright IBM Corp. 2008. All rights reserved. 191 10.1 The IBM Tivoli security portfolio
The IBM Tivoli portfolio of security products is represented in Figure 10-1.
IBM Tivoli Federated Identity Manager IBM Tivoli zSecure IBM Tivoli Access Manager TAM for Enterprise SSO TAM for e-business TAM for operating systems IBM TAM for Business Integration Tivoli IBM Security Tivoli IBM Tivoli Identity Manager (TIM) Operations Compliance Manager Insight (TSOM) Manager (TCIM) IBM Tivoli IBM Tivoli Directory Server Directory Integrator
Figure 10-1 IBM Tivoli security portfolio
The portfolio includes the following products (we indicate the commonly used acronyms, as of the time of writing, to designate these products). The IBM Tivoli Federated Identity Manager (TFIM) provides Identity Federation and SOA Security. It is a standards-based, access control solution for federated single sign-on (SSO) and trust management in Web services and SOA environments. The IBM Tivoli Security Operations Manager (TSOM) and IBM Tivoli Security Compliance Manager provide compliance and vulnerability assessment. Tivoli Compliance Insight Manager (TCIM) provides an enterprise with control for security compliance using a graphical interface dashboard. It also monitors, in detail, privileged user activity. TCIM operates on comprehensive auditing data that it collects from the systems it has connectivity to. IBM Tivoli Security Operations Manager (TSOM) is a real-time security information and event management (SIEM) platform designed to improve the effectiveness and efficiency of security operations and information risk management. TSOM centralizes and stores security data from throughout the heterogeneous technology infrastructure. The IBM Tivoli zSecure suite of products adds a user-friendly layer onto the RACF administrative interface, with additional audit, alert, and monitoring capabilities (the zSecure suite is discussed in 4.6.1, “IBM Tivoli zSecure administration products” on page 70). IBM Tivoli Access Manager (TAM) is a policy-based, access control security solution for e-business and enterprise applications, featuring Web-based single sign-on and distributed Web-based administration. For further information about TAM, refer to 10.2.1, “IBM Tivoli Access Manager (TAM)” on page 194.
192 Designing for Solution-Based Security on z/OS IBM Tivoli Identity Manager (TIM) provides a secure, automated, and policy-based user management solution that helps effectively manage user identities throughout their life cycle, across both traditional and e-business environments. TIM is discussed in more detail in 10.2.3, “IBM Tivoli Identity Manager (ITIM)” on page 210. IBM Tivoli Directory Server (ITDS) is a set of LDAP-based data repository products that can be hosted by different platforms, providing robust and advanced LDAP services and directories that can be exploited from any LDAP-compliant client application. ITDS, when running on a distributed platform, can be accessed from z/OS-hosted applications or middleware. Likewise, the ITDS for z/OS LDAP server can provide LDAP services to z/OS and non-z/OS hosted applications. ITDS is discussed in more detail in 3.2.3, “IBM Tivoli Directory Server for z/OS” on page 31, and in Chapter 6, “Using the LDAP directory as a User Registry” on page 91. IBM Tivoli Directory Integrator (ITDI) provides real-time synchronization between data sources so that enterprises can establish an authoritative, up-to-date, consolidated data infrastructure. TDI is discussed in more detail in 10.2.2, “IBM Tivoli Directory Integrator (ITDI)” on page 204.
10.1.1 Tivoli security products that can execute on z/OS
Some Tivoli security products (in addition to the zSecure suite discussed in 4.6.1, “IBM Tivoli zSecure administration products” on page 70, which is intended to run on z/OS) can be hosted in a z/OS instance and provide services to the various systems in the installation, including z/OS. Running these products on z/OS is not a requirement. However, installations may want to consider the infrastructure robustness and centralized operational advantages that this implementation yields.
The following products can run on z/OS: TFIM TIM ITDI ITDS
Note: In this book we focus on the capability of z/OS to host security services and products. In the following sections, however, we also indicate which other platforms each Tivoli product can execute on.
Products that are candidates for executing on Linux can be hosted by Linux for System z and, although they are not being installed on z/OS, they can still run in a logical partition of System z.
10.2 Tivoli security products used in our sample configuration
Chapter 11, “Sample configuration - identity provisioning, authentication and authorization” on page 219, describes the configuration we created for this project as an example of a typical security configuration many customers use today.
We used Tivoli security products in this configuration because they are mandatory players for achieving an optimum adaptation of existing installation infrastructures to the new approaches, standards, and technologies that the On Demand environment requires.
Chapter 10. Tivoli products that team with the mainframe 193 Because of planning constraints, we limited ourselves to using the products described in the following sections. However, all products described in “The IBM Tivoli security portfolio” on page 192 are useful in these infrastructures.
10.2.1 IBM Tivoli Access Manager (TAM)
TAM family of products The following products comprise the Tivoli Access Manager family: Access Manager for e-business (TAMeb) Access Manager for Business Integration (TAMBI) Access Manager for Operating Systems (TAMOS) Access Manager for Enterprise Single Sign-On (TAM E-SSO)
Note: Although Tivoli Access Manager for Enterprise Single Sign-On uses the same naming as the components mentioned here, it does not share the same core components. Therefore, the concepts and infrastructure that we describe here do not apply to TAM E-SSO.
This book focuses on Access Manager for e-business (TAMeb) and Access Manager for Business Integration (TAMBI).
For complete information about TAM, including its use and optimum placement in a security infrastructure, refer to the IBM Redbooks publication Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-6014.
The TAM concept Tivoli Access Manager (TAM) is an authentication and authorization solution for corporate Web, client/server, and existing applications. It implements access control to protected information and resources using a centralized, flexible, and scalable access control solution. It is particularly suitable for building secure and easily-managed, network-based applications and e-business infrastructure. TAM supports authentication, authorization, audit and logging, data security, and resource management capabilities.
In the simplest case, Tivoli Access Manager’s main purpose is to provide an authorization engine that returns a yes or no answer in response to a request by a particular user to perform a given action (or actions) on a given object.
The term “authorization engine” is specifically used here because it pertains to a concept where the access control function is offloaded from the requestor’s operating system. TAM runs on its own system (which can also very well be the requestor’s operating system). The authorization request and its response are sent via TCP/IP between the requestor and the TAM server.
Note that TAM is not intended to be a substitute for the existing native access control mechanisms implemented in operating systems. Instead, it aims at protecting resources meaningful only to instances of applications that run on different systems in the enterprise, but that still need to share the same access policy to these resources. Tivoli Access Manager contains two major components, a user registry and an authorization framework, as explained here: User registry TAM maintains a user registry in which it stores information about each TAM- registered user. The main information stored here is the user’s TAM identity and its group
194 Designing for Solution-Based Security on z/OS membership. Other information stored includes a password (which, optionally, can be used for user ID and password authentication), and policy information, such as last password change. TAM operates with an LDAP-based user registry that has to be implemented by the user. Refer to “TAM implementation details” on page 197, for a list of supported directory products. Authorization framework The authorization framework is used to make authorization decisions on behalf of applications written to use the TAM authorization API (the aznAPI). Decisions are made after querying the TAM authorization database. The database contains a hierarchical model of the object, the representation of resources being protected (the Protected Object namespace). Access Control Lists (ACLs) are attached to the objects in the namespace that define the security policy. Figure 10-2 provides a schematic view of the Protected Object namespace.
ProtectedProtected object object space space
BankApplication / servlet / stock-value Bank App Managem
Appl A
servlet Stock value
PolicyPolicy TemplatesTemplates User Peter ------T-m-rx- Group Employee ------T----rx- Corporate Web ACL uthenticated unauthenticated ------Employee Database ACL
Protected Object Policy Time-of-day access Privacy, Audit
Figure 10-2 TAM protected object name space
Objects to be protected are designated by entries in a hierarchical tree, and ACLs are assigned to the object, stating which users or groups of users can access the object and for which types of access. Note that an ACL, after it is assigned to an entry, is by default automatically propagated to all objects below the entry in the hierarchy. Objects are definitions of resources, usually at the installation level (such as servers, URLs, applications, messaging queues, and so on) over which a protection policy has to be shared by several systems in the installation.
Entries can also be assigned additional protection directives under the form of a Protected Object Policy (POP).
A high level view of the TAM implementation is shown in Figure 10-3.
Chapter 10. Tivoli products that team with the mainframe 195
Administration User registry and Access Control Lists at the Installation level Access Policy Enforcer System B Object / ACL Database
Policy Server LDAP Access Policy User Registry Enforcer TCP with SSL System C
Identity Yes/No Object Additional Action aznAPI information
Front-end Access Policy Protected Enforcer resource Application System A
Figure 10-3 The IBM Tivoli Access Manager concept
The core part of TAM, which is the Policy Server, does not itself protect application-owned resources. The Policy Server maintains the user registry and the Protected Object database (also called the Object/ACL database or the authorization database).
Application resources are protected using “Policy Enforcers” that reside between the front-end application that the user interacts with and the back-end application, or system, that contain the resources that require protection. The policy enforcer can be seen as a “plug-in” program to be installed in the path between the requesting application and the application or system that hosts the resource. IBM provides policy enforcers, and users can also design policy enforcers of their own.
When the Policy Enforcer receives a request from the front-end application, it uses the aznAPI to query the authorization database. It sends, via TCP/IP, information about the user making the request, the action being requested, and the object to be accessed. This results in a yes or no response which indicates whether the request should be accepted or rejected. The response can also contain data pertaining to a Protected Object Policy, if there is one.
The aznAPI is an Open Group standard for an authorization request API that is intended to be application- and platform-neutral, isolating requesting applications from the complexity of the access control decision-making processes.
Note: All communications between the TAM components can be protected with SSL/TLS.
196 Designing for Solution-Based Security on z/OS As shown in Figure 10-3, the TAM Policy Server can serve requests coming from policy enforcers on different systems, thus sharing the access policy in the Protected Object database between applications on these systems. In some cases, installations may install a Policy Enforcer that acts as a proxy agent, that is, an independent entity from the front-end and back-end systems. In other cases, the front-end, back-end and Policy Enforcer might be different parts of the same application.
To summarize, TAM implementations: Maintain a central user registry (users and groups; authentication information) Maintain a model of the Protected Objectspace (hierarchically organized) Define permitted actions on objects (using Access Control List templates which are attached to entries in the objectspace) Provide an API for making authorization queries Provide APIs for TAM administration
TAM implementation details The following sections provide implementation-related details.
User registry The following LDAP-based directories are supported by TAM, as of the time of writing: The IBM Tivoli Directory Server on z/OS or non-z/OS systems. The ITDS for z/OS LDAP server is used with the TDBM or LDBM back-end. The z/OS ISS LDAP Server with the TDBM back-end. Lotus Domino. Microsoft Active Directory. Microsoft Active Directory Application Mode (ADAM). Novell® eDirectory. Sun™ Java™ System Directory Server.
Note: When using the z/OS LDAP server as the TAM user registry, the schema files supplied in z/OS (schema.user.ldif and schema.IBM.ldif) already include the specific TAM user registry object classes and attribute types.
TAM Policy Server and additional components The Access Manager environment requires certain basic capabilities for administrative control of its functions. Management facilities are provided through the following base components: The Policy Server supports the management of the authorization database and its distribution to Authorization Services. A Policy Proxy Server provides a mechanism for Policy Enforcers to access Policy Server functionality without a direct connection to the master Policy Server. The Policy Proxy Server uses caching techniques with a local copy of the Policy Server access control database. The pdadmin utility provides a command line capability for performing administrative functions such as adding users or groups at the TAM policy server. The Web Portal Manager provides a browser-based capability for performing most of the same functions provided by the pdadmin utility. The administration API, on which the pdadmin utility and the Web Portal Manager are built, enables execution of program-initiated level administration tasks and queries.
Chapter 10. Tivoli products that team with the mainframe 197 As of the time of writing, the TAM Policy Server can run on the following operating systems: AIX HP-UX Linux Sun Solaris™ Windows
Resource managers Resource managers are program components that provide Access Manager authorization support for specific application types. A resource manager is responsible for the enforcement of the security policy within an Access Manager environment. The resource manager uses the Policy Enforcer to call the Tivoli Access Manager authorization service with the credentials of the user making the request, the type of access desired, and the object to be accessed.
The resource manager takes the recommendation of the authorization service, performs any additional verification actions, and ultimately either denies the request or permits the request to be processed.
WebSeal and WebSphere MQ TAMBI resource managers are described in the following sections.
TAM for e-business (TAMeb) - WebSEAL reverse proxy A real example of the front-end, Policy Enforcer, back-end arrangement is the way in which TAM can be used to protect Web resources. In this case, the front-end is a Web browser and the back-end is one or more Web-enabled servers. The IBM resource manager and Policy Enforcer, known as WebSEAL, acts as a reverse proxy sitting between the two. This is depicted in Figure 10-4.
Instead of making requests directly to the Web servers, the client is forced (using a firewall for example) to make requests to WebSEAL. When WebSEAL receives a request, it first authenticates the user and then makes a decision as to whether that user is allowed to access the resource they are requesting. WebSeal has a direct connection to the Policy Server LDAP user registry, so it can proceed directly to authenticating and collecting meaningful user characteristics.
If the user is authorized, WebSEAL passes the original request to the back-end server and then passes the response back to the user. If the user is not permitted, an error page is returned to the user and the request is discarded. In the simplest case, neither the browser or the back-end server have to be modified to achieve this functionality.
All the TCP/IP connections shown in Figure 10-4 can be secured with SSL/TLS.
As of the time of writing, WebSEAL can run on the following systems: Linux Windows UNIX
IBM also provides other Policy Enforcers such as a plug-in for the WebSphere Edge Server or for IBM or vendor-provided Web servers. The Web server plug-in can be installed on the following Web server products: Apache Web Server on AIX, Linux on System z, and Solaris IBM HTTP Server on AIX, Linux on x86, Linux on System z, Solaris and Windows 2003 Internet Information Services on Windows 2003 Sun Java System Web Server on AIX and Solaris
198 Designing for Solution-Based Security on z/OS
Other Policy Enforcers
Installation Can be LDAP on objects z/OS System x ACL TAM
Web LDAP Applications User Registry
Other Policy Enforcers
WebSEAL Authenticated and authorized Linux… HTTP user
Figure 10-4 TAM and the IBM WebSeal authorization reverse proxy
Junctions The back-end services to which WebSEAL can proxy are specified via junctions. A junction is a TAM configuration entity which defines a set of one or more back-end Web-enabled servers that are associated with a particular URL.
Single sign-on WebSEAL supports several mechanisms for supplying a junctioned server with the identity of the authenticated user, including: Providing the user’s identity via HTTP header values, which can be read and interpreted by the junctioned server. Inserting an HTTP basic authentication header to provide the junctioned server with login information for the user, including a password. Optionally, this basic authentication header can permit login to the junctioned server with an identity that is different than the one for the user who is logged in to WebSEAL. For junctions that support it (for example, WebSphere Application Server and Domino), inserting a Lightweight Third-Party Authentication (LTPA) cookie identifying the user into the HTTP stream that is passed to the junctioned server. For junctions that support it (WebSphere Application Server), using a Trust Association Interceptor Plus (TAI++) to forward Tivoli Access Manager credential information and establish trust between WebSEAL and the back-end application server. Refer to “WebSphere Application Server Trust Association Interceptor (TAI)” on page 165, for more information about TAI.
Chapter 10. Tivoli products that team with the mainframe 199 TAM auditing - Common Auditing and Reporting Services (CARS) Tivoli Access Manager includes the IBM Common Auditing and Reporting Service (CARS) platform, which provides a consistent way to audit and report on data. CARS automates the collection of audit data and provides the ability for enterprises to centrally view and report audit data that are critical for compliance needs, and thus provides a more efficient audit process.
For details about TAMeb auditing and CARS, refer to Tivoli Access Manager for e-business 6.0 Auditing Guide, SC32-2202.
TAM for Business Integration (TAMBI) Tivoli Access Manager for Business Integration (TAMBI) operates in conjunction with IBM Tivoli Access Manager for e-business. The combination of these software applications is provided as a security solution for IBM WebSphere MQ products. TAMBI provides the following services: Data protection for MQ messages It secures sensitive or high-value messages, providing integrity and privacy protection for data as it flows across the network and while it is in a queue. It also detects and removes rogue or unauthorized messages before they are processed by a receiving application. Access control for IBM MQ Resources It provides control over which users have access to specific queues, and generates detailed audit records showing which messages were expressly authorized and encrypted. Central Management of Security Policy Definition and Enforcement It defines authorization and data protection policies centrally for IBM WebSphere MQ resources that get and put messages to queues, using a Web browser or command line. Support for existing and new MQ applications It secures existing off-the-shelf and customer-written applications for IBM WebSphere MQ.
MQ uses the operating system identity that an MQ application is running under to make its authorization decisions. MQ relies, therefore, on the local operating system for authentication and has locally administered authorization.
Although MQ is able to perform data encryption and integrity using the security or message exits, these only provide data protection when a message is traversing the network. Channel exits do not protect messages while they are on the queues.
TAMBI exploits the X.509 digital certificate technology to globally identify users and processes. In most cases, this is mapped from the operating system identity. If “real” users are using MQ applications locally, then they can be prompted for a digital certificate identity, which is independent of the operating system user.
Also, the operating system definitions for the same person on multiple MQ systems can be mapped to a single identity in TAMBI. This means that changes to a user’s access rights made centrally are immediately enforced on every MQ system in the secure domain. Each TAMBI user is mapped to a digital certificate identity. This also means that this infrastructure can be directly exploited for messages to be encrypted for the intended recipients, or signed by the sending user or process.
A high level representation of the TAMBI implementation is shown in Figure 10-5.
200 Designing for Solution-Based Security on z/OS
Customer
Application ACLs
MQCONNECT Authorization MQOPEN MQPUT MQGET Services Users
Crypto Services MQSeries PD/MQ
Queues Queue Manager MCA
OAM Code Exits
Not used with TAMBI Not used with TAMBI
Figure 10-5 TAM BI high level view of implementation
When TAMBI is used, it intercepts requests made by the MQ application. This is done in various ways, depending on the platform.
Because all requests made by the application now pass through TAMBI, it can completely control what actions the application can perform. It can also make changes to the messages sent by the application to include data signing and data encryption.
TAMBI uses the services of TAM to make authorization decisions. TAMBI uses digital certificate technology and symmetric key algorithms to perform the required signing and encrypting.
Note: The Object Authority Manager (OAM), which is the native MQ authorization engine, is redundant with TAMBI and is not expected to be used. Likewise, the Message Channel Agent (MCA) code exits, which are available to provide authorization of exchanges between MQ systems or to encrypt/decrypt the message data as it flows over the network, are not expected to be exploited when TAMBI is in use.
The user sets up the following policies in the Policy Server authorization database: An Access Control Policy, which gives permissions for the PUT and GET operations. A Data ProtectionPolicy that specifies the Quality of Protection (QoP) level. The QoP level can be: –NONE – DATA INTEGRITY CHECKING – DATA INTEGRITY CHECKING and DATA PRIVACY
Chapter 10. Tivoli products that team with the mainframe 201 Auditing can be specified for a queue, in which case all OPEN, PUT, GET actions are recorded. The audited information includes: TAM identity of application or user Date and time Encryption and signing algorithms used Sender (if the message is digitally signed) MQ Message ID
TAMBI for z/OS TAMBI for z/OS is marketed, as of the time of writing, as “Access Manager Business Integration Host Edition” (AMBIHE). Further details about AMBIHE can be found in IBM Tivoli Access Manager for Business Integration, Host Edition Administration Guide, GC32-1122.
As with the other TAMBI implementations, AMBIHE is designed to enforce two specific access rights, that is, whether an application is authorized to put and/or get messages to a queue.
AMBIHE also supports the following options for data protection policies: NONE (No data protection) INTEGRITY(Sign message data to allow verification) PRIVACY (Sign and encrypt message data for integrity and confidentiality)
AMBIHE cryptographic functions exploit the System z cryptographic hardware coprocessors, whenever possible.
The auditing of access to protected resources is also part of each policy. If auditing is enabled, then Generalized Trace Facility (GTF)) records are provided that document the success or failure of attempts to open and close queues and put and get messages. The specific audit options are: NONE (Records any unsuccessful intercepted API operations) Any other specified option (Records OPEN, CLOSE, PUT, and GET operations on protected WebSphere MQ queues)
AMBIHE uses public and private keys to perform its data-protection functions. Certificates are managed by RACF and associated with RACF user IDs. AMBIHE can utilize digital certificate credentials generated by most popular third-party Certificate Authorities, including VeriSign, Entrust, Baltimore, and Netscape, in addition to the self-signed certificates it can generate itself. These credentials are stored and secured using RACF.
Figure 10-6 provides a high level view of the AMBIHE implementation.
202 Designing for Solution-Based Security on z/OS
z/OS Other Policy Enforcers RACF
Resource Manager S Installation A objects ACL F Access authorization and resource attributes MQ TAM Applications MQ BI
PDAS LDAP User Registry
z/OS Policy Director Authorization Services Other Policy Enforcers
Can be LDAP on z/OS
Figure 10-6 High level view of AMBIHE implementation in z/OS
AMBIHE comes with the Policy Director Authorization Services (PDAS) component that has to be installed in z/OS. It comprises a z/OS UNIX version of the TAM pdacld (Policy Director ACL daemon) remote authorization engine. The pdacld daemon maintains a replica of the authorization database on the z/OS host. However, rather than providing authorization services to remote clients as in the distributed environment, it mirrors the policy information to a cache in z/OS where it can be accessed by the local resource managers.
When PDAS is installed, the SAF interface is extended to provide support for the following SAF callable services that are specific to AMBIHE: aznCreds This callable service is a z/OS version of the azn_id_get_creds and azn_creds_delete aznAPI functions. The identity that is supplied with the call can be a TAM user identity, or it can be a RACF user ID presented in a z/OS ACEE control block. aznAccess This callable service is the z/OS version of the azn_decision_access_allowed aznAPI functions. The identity that is supplied can be a TAM user identity, or it can be a RACF user ID presented in a z/OS ACEE control block. Protected resource attribute values and Protected Object Policy values may also be optionally returned. R_cacheserv This callable service allows you to store and retrieve information from a cache (actually, a data space) managed by RACF. In the context of PDAS, it is exploited by pdacld to mirror the Policy Server authorization database. R_proxyserv This callable service exploits the z/OS LDAP server PC-callable support to retrieve TAM user registry information.
In addition to the auditing data collected at the TAM Policy Server level, PDAS operations are audited and recorded in SMF type 80 and 180 records. For details about SMF type 80 record content, refer to z/OS Security Server RACF Macros and Interfaces, SA22-7682. For details
Chapter 10. Tivoli products that team with the mainframe 203 about SMF type 180 record content, refer to IBM Tivoli Access Manager for Business Integration Host Edition Administration Guide, GC32-1122.
10.2.2 IBM Tivoli Directory Integrator (ITDI)
IBM Tivoli Directory Integrator (ITDI) is an open architecture-based solution used to synchronize and exchange information between applications or directory sources of many different types and data formats. It operates with an AssemblyLine methodology that builds a compound information object from connected information sources; performs modifications on received data; or creates new entries altogether and adds, updates, or deletes the new information object to the assigned destinations.
It is particularly well adapted to performing the following tasks: Serving as a flexible synchronization layer between an installation’s identity structure and the application sources of identity data, thus eliminating the need for a centralized data store Helping to ease the process of deploying an enterprise directory solution by connecting to the identity data from the various repositories throughout the organization Managing data across a variety of repositories, thus providing a consistent directory infrastructure that can be exploited by a wide variety of applications And creating authoritative data spaces that are needed to expose only trustworthy data to advanced software applications such as Web services
Data Integration-relevant concepts Data sources and targets These are the data repositories, systems and devices that feed data into, or get data from the dataflows. Data flows These are the threads of communications and their content. Data flows are usually drawn as arrows that point in the direction of data movement. Each data flow represents a dialog between two or more systems. Events Events can be described as the circumstances that dictate when one set of data sources communicates with another (for example, whenever an employee is added to, updated within, or deleted from a user registry).
Conceptual view of ITDI operations Figure 10-7 illustrates a conceptual view of ITDI operations, where a schematic “assembly line” shows the collection of data coming from LDAP and the ODBC directory. This data is eventually processed and reformatted as a JMS message and a Lotus Notes® database update.
204 Designing for Solution-Based Security on z/OS
Main- AIX frame
MQ Main- Database frame ITDI WebWeb ServicesServices
Directory XML Document Linux .net
JDBC LDAP FileSystem Connector Connector Connector w/ XML Parser
Assembly Line
SQL LDAP database directory
Figure 10-7 ITDI concept of operations
ITDI includes Connectors to support numerous protocols; Parsers to interpret and translate information from a byte stream into a structure information object, and Hooks to enable the definition of certain actions to be executed under specific circumstances. ITDI also exploits an EventHandler framework that adds to the flexibility by providing the ability to wait for, and react to, specific events that have taken place in the infrastructure
ITDI can typically be used to satisfy the following needs: Continuously maintain records in one or more databases, based on information in other data sources such as files, directories and databases Migrate data from one system to another, or synchronize with pre-existing data where systems cannot be replaced or shut down Automatically transform files from one format to another Add supplementary identity data to LDAP directories when deploying user registry, provisioning, and access control solutions React to changes to data (such as modification, additions, and deletions) in the infrastructure, and drive this information to systems that need to know about it Integrate geographically dispersed systems with multiple choices of protocols and mechanisms such as MQ, HTTP, secure e-mail and Web Services
Supported operating systems ITDI can execute on the following operating systems: AIX HP-UX Linux
Chapter 10. Tivoli products that team with the mainframe 205 Sun Solaris Windows i5/OS z/OS
Synchronizing data with ITDI When implementing a synchronization solution, the result is an environment where shared data looks the same for all consuming applications. This is because changes are propagated throughout the synchronized network of systems, and molded in transit to fit the needs of each consumer. Each data source is kept up-to-date, maintaining the illusion of a single, common repository. Each application accesses its data in an optimal manner, utilizing the repository to its full potential without creating problems for the other applications.
Tivoli Directory Integrator-based synchronization solutions are typically deployed in one of the three following ways, although combinations are also frequently used to enable the various data flows that entire solution requires. Batch In this mode, ITDI is invoked in some manner (through its built-in timer, command line or the Tivoli Directory Integrator API), and is expected to perform some small or large job before either terminating or going back to listening for timer events or incoming API calls. This mode is often used when synchronizing data sources where the latency between change and propagation is not required to be near real-time. Event ITDI can accept events and incoming traffic from a number of systems, including directory change notification, JMX™, HTTP, SNMP, and others. This mode is typically used when ITDI needs to deal with a single data object, or a small number of data objects. Call-reply Call-reply is a variation of the event mode, but the difference is that the originator of the event expects an answer back. IBM products use the ITDI API to call Tivoli Directory Integrator, and solutions in the field often use HTTP, MQ/JMS and Web services to invoke an ITDI rule and get a reply back.
Data synchronization security It is important to identify the security requirements of the data that users will be synchronizing. Most of the requirements become apparent while identifying the nature of the data and planning the data flows. The following two questions can be asked to further identify these requirements: Does the entire data transmission between sources have to be secure for all data? Solutions for securing the data transmission involve utilizing technology such as SSL/TLS protection of the communications. Are there specific data attributes that must be encrypted? Many times this involves the password attribute. ITDI provides several encryption methods and the ability to encrypt any attribute; it is not limited to simply the password attribute.
Non-data synchronization scenario Although ITDI can deal with a large number of synchronization scenarios, its core is a general purpose integration engine that can be used by other systems in real-time, thus providing these systems with interesting capabilities. An example of such a deployed solution might be a mainframe application that sends MQ messages that ITDI picks up. ITDI then accesses other data systems in the enterprise, performs operations and transformations on the set of data, and responds back through MQ to the mainframe.
206 Designing for Solution-Based Security on z/OS ITDI component structure ITDI is a Java-based system in which the core system provides most of the functionality. The core handles log files, error detection, dispatching, and data flow execution parameters.
There are four main types of components that provide an abstraction layer for the technical details of the data systems and formats that users exploit: AssemblyLines, Connectors, Parsers, and EventHandlers; see Figure 10-8.
AssemblyLines Execute data flows based on the configuration of individual Connectors. EventHandlers, Parsers and the business logic EventHandlers driving process Enable the system to respond to predefined events, thus enabling real-time Directory integration
Event Systems
Connectors Connect to a device, system or RDBMS application and perform actions LDIF File on data appropriately Parsers Interpret and transform incoming Changed data into the desired format attributes
Change log Target directory
Figure 10-8 ITDI components
We explain these components in more detail here, along with additional facilities such as hooks, scripts, and function components.
AssemblyLine AssemblyLine (AL) refers to a set of components strung together to move and transform data. It is the “unit-of-work” in ITDI and typically represents a flow of information from one or more data sources to one or more targets. Data to be processed is fed into the AL one entry at a time. These entries carry attributes with values coming from directory entries, database rows, e-mails, Notes documents, records or similar data objects. Each entry carries attributes that hold the data values read from fields or columns in the source system.
The attributes are renamed, reformatted, or computed as processing flows from one component to the next in the AL. New information can be “joined” from other sources, and all or part of the transformed data can be written to target stores or sent to target systems as desired.
Connectors Connectors provide access to data while “abstracting away” the details of some system or store, giving the user the same set of access features.
There are basically two categories of Connectors: In one category of Connectors, both the transport mechanism and the structure of the data content are known to the Connectors (that is, the schema of the data source can be queried or detected using a well-known API such as JDBC or LDAP). In the other category, the transport mechanism is known, but the content structuring is not known to the Connectors. This category requires a Parser to interpret or generate the content structure in order for the AssemblyLine to function properly.
Chapter 10. Tivoli products that team with the mainframe 207
Note: When running on z/OS, ITDI can use the z/OS TSO Command Line Function component to interact directly with z/OS components such as RACF.
Parsers Unstructured data, such as text files and bytestreams coming over an IP port, can be handled by passing the bytestream through one or more Parsers. ITDI is shipped with a variety of Parsers, including LDIF, Directory Services Markup Language (DSML), XML, comma-separated values (CSV), SOAP, and fixed-length field. As with Connectors, users can extend and modify these Parsers, as well as create their own.
EventHandlers EventHandlers enable the system to respond to predefined events, thus enabling real-time integration.
Hooks Hooks enable developers to describe certain actions to be executed under specific circumstances or at any desired points in the execution of an AssemblyLine.
Scripts The ITDI implementation provides the ability to extend most of its integration components, functions, and attributes through scripts or Java. Scripting can be installed anywhere in ITDI to add or modify the components of an AssemblyLine.
Function component The function component is an AssemblyLine wrapper around some function or discreet operation that allows it to be dropped into an AssemblyLine as well as instantiated, or invoked, from a script.
ITDI use case example Figure 10-9 illustrates an example of an ITDI use case, where an installation wants to synchronize, both ways, an LDAP user registry and the RACF database. In this example, the LDAP user registry is actually the z/OS LDAP server with the TDBM or LDBM back-end. The access to the RACF database is also achieved with the LDAP protocol via the z/OS LDAP SDBM back-end (refer to Chapter 6, “Using the LDAP directory as a User Registry” on page 91, for a discussion of the z/OS LDAP and its back-ends).
Figure 10-9 also shows the LDAP user registry as being a TAM policy server user registry.
208 Designing for Solution-Based Security on z/OS
New TAM user RACF administrator TAM administrator ITDI – Assembly Line 1
Add Add Get New To Native User RACF Auth
RACF z/OS LDAP ADDUSER
TDBM SDBM GDBM Users /LDBM TAM
LDAP user Installation registry objects ACL
Add Add Get New Native To User Auth LDAP
ITDI – Assembly Line 2
New RACF user Figure 10-9 ITDI use case example
New user creation in the TAM user registry 1. When an LDAP directory entry creation event is detected, ITDI starts AssemblyLine 1 (AL 1).
Note: The event detection can be performed through the GDBM back-end of the z/OS LDAP server.
2. AL 1 fetches the user data from the LDAP directory and establishes, in the newly-created user entry, the object class and attribute necessary to exploit the native authentication feature of the z/OS TDBM or LDBM back-end. 3. The ITDI AL1 reformats the user attributes and their values as fetched from the TAM user registry into object classes and attributes that are supported by the z/OS LDAP back-end. 4. The ITDI AL1 creates a RACF profile for the new user, through the SDBM back-end, by using the LDAP protocol and commands.
New user creation in the RACF database 1. When a RACF “directory entry” creation event is detected (actually the creation of a new USER profile, but as seen through the SDBM), ITDI starts AssemblyLine 2. 2. AL 2 fetches the user data from the RACF database.
Note: The event detection is done through the GDBM back-end of the z/OS LDAP server.
3. AL 2 reformats the RACF user data into object classes, attributes, and values that match the LDAP schema of the TAM user registry. This includes the attributes for the TDBM or LDBM z/OS LDAP native authentication.
Chapter 10. Tivoli products that team with the mainframe 209 4. AL 2 creates the new user entry in the TAM user registry.
Auditing Although providing functional logging and tracing facilities, ITDI does not provide built-in auditing functions in the security sense of the term. However, AssemblyLines can be assembled that would feed audit or log files.
For further information about ITDI, including its use and optimum placement in a security infrastructure, refer to IBM Redbooks publication Robust Data Synchronization with IBM Tivoli Directory Integrator, SG24-6164.
10.2.3 IBM Tivoli Identity Manager (ITIM)
IBM Tivoli Identity Manager (ITIM) provides a secure, automated, and policy-based solution that helps effectively manage user privileges across heterogeneous IT resources with the following implementations: Comprehensive request-based provisioning for users, managers, or delegated administrators to easily request (with approval workflow) user access to roles, accounts or fine-grained Access Entitlements such as shared folders and Web portlets on distributed systems Streamlined self-service interface for users that can be easily customized by the using organization and integrated with corporate portals, to help improve user productivity and reduce administrative cost Comprehensive reporting and auditing facilities
The entities managed by ITIM To implement the concepts involved in Identity Management, the ITIM functional architecture is based on the following entities that are to be managed.
User In the common meaning of the term, a user is a person whose identity must be managed across an organization by ITIM. Be aware that a user might not be part of the organization itself but, for business reasons, needs to have a registered identity in the organization.
Account Here, the term account refers to the collection of information, mainly dictated by the technology of the user registry in use, which together makes up an identity that the technology can exploit.
Attribute The term attribute refers to the additional meaningful information associated to the user that the exploiting organization wants to find in the account.
Password Every account has a password. Account passwords can be centrally managed by their owners or administrators using the Identity Manager Web interface. Passwords are managed in a secure environment. ITIM provides two options for the passwords it manages: passwords can be synchronized, or not.
Password synchronization is the process that helps users maintain a single password that is subject to a single password policy, and changes on a single schedule across multiple systems. The synchronization can be applied to all accounts associated with a user or with
210 Designing for Solution-Based Security on z/OS selected accounts. This is mostly one-way synchronization, because Identity Manager sets the password and pushes it to the managed targets. (There are a few target systems where local password changes can be reflected back to ITIM so that they can be propagated to the other managed systems, but the ITIM RACF agent does not provide reverse password propagation.)
When the password synchronization property is enabled, there is only one global password that a user uses for all the applications managed by Tivoli Identity Manager. If an account is being set up for first time, password synchronization does not apply; there is only one account, and therefore, one password.
If a user has more than one account, password synchronization affects the following user or administrator actions: Creating a new account Changing a password for an existing account Provisioning an account Resetting an expired or forgotten password for an existing account Restoring an account that was suspended
Administrators can always change passwords for selected accounts by using service account management, but this would imply that a user will have different passwords across platforms or applications.
There is a process where Identity Manager generates a random password. This can be displayed to an administrator or mailed to a user.
Notes: When RACF is part of the ITIM-managed system, the password length and syntax specified in the ITIM password policy must conform to the RACF rules and syntax. The ITIM RACF adapter does not reflect to ITIM a RACF password change that is performed at RACF. If password reconciliation and resynchronization is required in such cases, the installation has to set up the infrastructure described in “Complementing ITIM with ITDI” on page 216 to feed back to ITIM back the new RACF password.
Group memberships A user’s membership in a group is granted by ITIM by specifying a group attribute in accounts.
Managed systems and applications ITIM manages users on many managed systems. These include operating systems (such as many flavors of UNIX and Windows servers) and applications (such as databases and business applications).
ITIM management entities Identity Manager uses the following entities in its identity management processes.
Organizational tree and roles The organizational tree (org.tree) defines the structure for the organization that ITIM is being deployed into in order to provide the Identity Management services.
The organization tree consists of various entities, as explained here: An organization
Chapter 10. Tivoli products that team with the mainframe 211 There is normally only one organization at the top of the organizational tree. One or more locations These are locations defined by the business. One or more organizational units These are teams or departments as defined by the business. One or more business partner organizations These are business partners as defined by the business. One or more administrative domains These are Identity Manager groupings for administration.
There is no technical difference between locations, organizational units, or business partner organizations. They simply use different icons in the administrative interface and allow the org.tree to be modelled according to the administrator’s plan.
All people are attached to the org.tree at a single point. A policy is attached to points in the org.tree. This policy can control the provisioning of accounts, account user ID generation, and password strength. Thus, there can be a corporate-wide password policy defined at the organization level in the organizational tree, and a specific password policy that applies to a specific branch or department of the organization.
Identity Manager roles Identity Manager roles, or “organizational roles”, are also attached to points in the organizational tree. These roles define the scope of specific access rights within the Identity Manager product.
Users are assigned to roles based on responsibilities defined within the organization. Role members are provisioned to resources via a Provisioning Policy.
Important: ITIM does not create or delete groups on managed target systems, nor does it manage ACLs or resource access on the managed targets. These tasks must be performed by local administrators or application owners using the native system or application tools.
Policy Identity Manager employs four types of policy: provisioning policy, password policy, identity policy, and service selection policy, as explained here. Provisioning policy A provisioning policy is used to define what accounts can be created for a user, and on which target systems. It can, optionally and automatically, create the accounts on those systems. It can also be used to define a specific approval workflow process that has to be applied to the accounts. Password policy A password policy sets parameters that all passwords must meet, such as length, type of
characters allowed and disallowed, and so on. Identity policy An identity policy defines how a user's ID is created. Identity Manager automatically generates user IDs from the identity policy. Service selection policy
212 Designing for Solution-Based Security on z/OS A service selection policy extends the ability of provisioning policies by provisioning a specific instance of a service based on installation-given attributes to the specified user ID. Workflow
ITIM can be set up to execute workflows (that is, internal automated processes) that can be used, for example, to customize account provisioning using entitlement workflows, and provide automated or semi-automated life cycle management, such as adding, removing, and modifying people and accounts in ITIM using operation workflows. Workflows can also be used to obtain approval before starting a provisioning process.
Audit logs ITIM logs events that occur during specific transactions. A few typical events are listed here (this list is not comprehensive): Add, modify, suspend, restore, delete person Add, modify, suspend, restore, delete account Change password Add, modify, delete provisioning policy
Reports ITIM provides several types of reports that can be used for administering and tracking activities.
ITIM key functions and logical architecture The following list summarizes ITIM key functions. User self-service This allows users to maintain their account passwords and other personal information Password management Through ITIM, users and administrators can centrally manage and synchronize their passwords across all their accounts (that is, across systems and repositories where users are registered). Manage people and accounts System administrators can manage an organization’s employees (people) from a central location. Apply policy to people and account management Policies are used to determine and enforce compliance of people and their accounts managed by Identity Manager. Policies are also used as the basis for automation of account provisioning and deprovisioning, account ID creation, and password strength checking. Apply workflow to people and account management Workflows are a technical representation of specific business processes in ITIM, and they can be used to complement account provisioning and life cycle management activities, such as adding, removing, and modifying people and accounts in ITIM and managed resources across the environment.
ITIM logical architecture ITIM is a Java application with a logical architecture as shown Figure 10-10.
Chapter 10. Tivoli products that team with the mainframe 213
End User Administrator Supervisor browser browser browser
User/Administrator requests/responses Transactions info, schedule Entity puts/gets reads/writes Web User Interface
Java API
Application LDAP Database
Service
Account provisioning/reconciliation
Adapter Adapter Adapter
Operating RDBMS Application System
Figure 10-10 ITIM logical architecture
This architecture is composed of three main functional layers, as explained here: The Web User Interface layer This is the interconnecting layer between the user’s browser layer and the identity management application layer. The Application layer This is the core of ITIM, and it runs on the application server. The Application subsystem contains all modules that provide provisioning-specific capabilities, such as identity management, account management, and policy management. The Service layer This Core Services subsystem contains all modules providing general services that can be used within the context of provisioning, such as authentication, authorization, workflow, and policy enforcement. This also includes communication, both with the adapters residing on the managed services, and to directories for information storage.
IBM Tivoli Identity Manager system uses an LDAPv3 directory server as its primary repository for storing the current state of the enterprise it is managing. This state information includes identities, accounts, roles, organization chart, policies, and workflow designs.
A relational database is used to store all transactional, reporting and schedule information. Typically, this information is temporary for the currently executing transactions, but there is also historical information that is stored indefinitely to provide an audit trail of all transactions that the system has executed.
ITIM can be hosted by the following platforms:
214 Designing for Solution-Based Security on z/OS HP-UX IBM AIX Red Hat Enterprise Linux Sun Solaris SUSE® Linux Enterprise Server
Windows 2003 Server z/OS
ITIM RACF adapter ITIM is connected by TCP/IP to the z/OS instances to which it provides identity management services. The ITIM commands sent to the adapter, and responses to these commands are exchanged using Directory Access Markup Language (DAML) messages between ITIM and the RACF adapter installed in z/OS, as shown in Figure 10-11.
DAML over TCP/IP Started Task APPC Transactions
Tivoli Identity z/OS Platform Manager Server
RACF SSL Command Service Form Agent operating Processor in UNIX System operating in ADMINX Services APPC/MVS
« RACF ID under which RACF ID RACF ID used requests will be assigned to for processing processed » field on agent is requests will be service forrm is set to « ITIAGNT » « ADMINX » « ADMINX » Defined as SPECIAL Optional (to administer subpopulations) or GROUP SPECIAL otherwise is executed with RACF ID « ITIAGNT »
Figure 10-11 ITIM RACF Adapter
The RACF adapter is composed of two parts to be installed in the z/OS system: A z/OS UNIX-based TCP/IP agent, to directly interface with ITIM The ITIM agent is a z/OS started task listening for requests coming from ITIM. When such a request arrives, the agent uses APPC to trigger a command processor program in z/OS. Note that the TCP/IP communication between ITIM and the RACF agent is protected with SSL/TLS. The RACF command processor This is a set of APPC programs that issue RACF commands, or start RACF utilities, and send responses back to the ITIM agent.
Figure 10-11 also shows examples of a RACF user ID being used for the execution of the agent or the command processor programs: ITIAGNT is the RACF user ID assigned to the agent started task. It has been defined with the SPECIAL attribute (if ITIM is to manage all users in the RACF database), or with a
Chapter 10. Tivoli products that team with the mainframe 215 GROUP SPECIAL attribute (if ITIM should be in charge only of certain users in the RACF database). ADMINX is an existing RACF user ID that can be optionally specified at ITIM. In this case, the RACF commands are run under this user ID. The purpose of this facility is to support the management of subpopulations of ITIM-administrated RACF users, using specific administrator user IDs. Note the following points: – If this facility is used, then ITIAGNT does not need any specific attribute in itself; however, it should be defined as a surrogate of ADMINX. – If this facility is not used, then the RACF command is executed under the ITIAGNT user ID.
ITIM LDAP adapter There is an ITDI-based LDAP adapter that can be installed on different platforms, including z/OS.
Complementing ITIM with ITDI We have seen that ITDI could also be used alone to synchronize passwords. However, it is strongly recommended that whenever password synchronization is part of an identity management strategy, ITIM be used to distribute synchronized passwords. The reason for this is because ITIM has a complete view of the accounts to be managed, which ITDI does not have.
As mentioned, the ITIM RACF adapter does not allow you to reflect local changes to a RACF password back to ITIM. Assuming that an installation requires that all passwords in the installation be resynchronized to the new RACF password, the infrastructure shown in Figure 10-12 provides this function.
216 Designing for Solution-Based Security on z/OS
User changes 1 3 RACF password EventHandler
z/OS LDAP changelog event handler polls the changelog to look for RACF password change and starts AssemblyLine 2 ITDI Services AssemblyLine
5 Connector posts password LDAP Connector change request to ITIM gets the password change over a secure connection 4 ITIM Application Server ITIM password synch function ITIM receives the ITIM 6 Agent synchronization request Agent Windows and the user’s password is AIX XP updated for all accounts the person owns
Figure 10-12 Organizational account resynchronization on a new RACF password
The event flow illustrated by the numbers in Figure 10-12 is described here. 1. A user changes his password in RACF. This password change gets recorded in the z/OS LDAP GDBM changelog and a password envelope is created. The Directory Integrator EventHandler for z/OS LDAP detects the password change. 2. The EventHandler calls a Directory Integrator AssemblyLine that is composed of two connectors: – The first connector securely retrieves the encrypted password attribute and decrypts it with the supplied API in Directory Integrator. – The other connector builds the XML structured request to ITIM to request the password change. The connector performs an HTTP post to the ITIM password synchronization servlet to make the password change request. 3. ITIM receives the password synchronization request for its use and checks to see what other accounts are eligible for password synchronization. Password change requests are then automatically initiated for the eligible systems (for example, AIX, Windows NT®, Active Directory, and so on).
For further information about ITIM, including its use and optimum placement in a security infrastructure, refer to IBM Redbooks publication Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996.
Chapter 10. Tivoli products that team with the mainframe 217
218 Designing for Solution-Based Security on z/OS
11
Chapter 11. Sample configuration - identity provisioning, authentication and authorization
Today, IT customers face many situational challenges. Different organizational domains must be connected, and users must be identified and authenticated outside of their home organization. This frequently leads to a multiplicity of user registries with specific provisioning and synchronization needs. Applications also have differing needs for authentication and authorization technologies, and are often accessed through multiple channels.
During this project, we developed and experimented with a sample configuration that represents many customer situations today. Our purpose was to show a “live” example of an identification and authorization infrastructure, taking advantage of the functions and products described in this book. (Note that this may not be the optimum or only configuration possible; it is presented only for purposes of demonstration.)
Many readers will be familiar with the way security services are provided to existing middleware and applications, and may also be aware that an implementation that includes WebSphere Application Server would be more representative of the current, ongoing technological journey to SOA and the specific requirements and challenges involved.
© Copyright IBM Corp. 2008. All rights reserved. 219 11.1 Our sample configuration
Our sample configuration is shown in Figure 11-1.
Business Partner Corporation
Windows Active Directory DB2 client Restricted Zone Kerberos KDC Windows
Kerberos 3 authentication LDAP 8 User 5 registry 1 z/OS DDF AIX WebSphere SOAP WebSphere CICS Application DB2 Server Web service Application Server 6 IPSec VPN RACF Windows IP Filtering Security browser IDS … 7
RACF
EJBROLE
LDAP DMZ authentication
Linux 4 5 Linux customers z/OS LDAP User registry WebSEAL IBM 2 Authentication Tivoli proxy Access browser Manager
Windows
Hardware crypto
Figure 11-1 Our sample configuration
In this scenario, there are three organizational domains: Corporation Business Partner Customers
These organizational domains have the following interactions, as illustrated by the numbers in the figure:
1 The Corporation and the Business Partner communicate using Web services. A Web service request triggers a CICS transaction in the Corporation’s z/OS system.
220 Designing for Solution-Based Security on z/OS 2 Business Partner employees and Customers can connect to the Corporation WebSphere Application Server using plain HTTP. Their requests are authenticated by an HTTP reverse proxy 4. We used the Tivoli WebSEAL authentication proxy that operates with Tivoli Access Manager 7.
3 Some corporate users are Windows users. In our sample configuration, they connect to a DB2 server in z/OS using Kerberos tickets for authentication. The Kerberos Key Distribution Center is the Microsoft Active Directory 8.
5 LDAP directories are used as the user registry by the Business Partner; by the WebSphere Application Server that runs in the Corporation’s z/OS; by TAM; and by the WebSEAL HTTP authentication proxy.
6 The WebSphere Application Server for z/OS uses: – The corporate z/OS LDAP for user authentication –TAM 7, with the JACC interface, for J2EE role authorization. (Alternatively, it can be set up to invoke RACF for J2EE authorization, if the proper EJBROLE or GEJBROLE profiles have been defined in RACF.) – RACF, to protect WebSphere Application Server runtime resources.
Network security Addressing network security aspects is beyond the scope of this sample, but we do illustrate the two main security zones to consider: The DeMilitarized Zone (DMZ) where TAM is located, to interact both with external users and the corporate z/OS system The Restricted Zone, which is expected to be shielded from external threats
For Business Partner-to-Corporation SOAP communications, we indicate the possible exploitation of the z/OS Communications Server network built-in protections: IP Filtering, IPSec VPNs, and Intrusion Detection Services (IDS). These functions, which are discussed in more detail in 8.4, “z/OS network protection” on page 131, may not be sufficient in all cases, but they must be taken into consideration.
Note, however, that as in many real installations, the use of asserted identity for the requests coming from the Business Partner organization to the WebSphere Application Server appears to be an attractive solution. For our sample configuration, we decided that establishing an IPSec VPN between the Business Partner and the Corporation organization would provide adequate protection and might help to simplify the network security infrastructure in support of these communications.
11.1.1 User populations and user registries
Based on the organizational boundaries in our sample configuration, we distinguish three populations of users, as explained here.
Corporate users The corporate users comprise both “real” users and technical users (the user IDs that subsystems, middleware or applications run under) that operate only within the Corporation organizational boundary. Their population is subdivided into the following categories: A subpopulation of users accessing the z/OS system using TSO, CICS, or DB2, and who use RACF authentication only.
Chapter 11. Sample configuration - identity provisioning, authentication and authorization 221 A subpopulation that must also proceed with LDAP authentication (as with corporate users that need to authenticate to the WebSphere Application Server in z/OS) This subset divides between: – Users that keep their password in their RACF profiles (by exploiting the native authentication feature of z/OS LDAP). – Users that do not exploit native authentication and therefore need to have their RACF password duplicated into their LDAP user entry. Native authentication might not be exploitable in cases where, for instance, a native authentication subtree cannot be built in the directory because of topology constraints and the ibm-nativeID attribute cannot be used.
Important: We are assuming that RACF users are primed by ITIM with a temporary password to be changed at the first logon verification performed by RACF. The new password must then be reflected in the LDAP entries of these users.
The corporate Windows users. We are assuming that these users only need to directly authenticate to Windows Active Directory and therefore do not need LDAP user entries or RACF USER profiles. These users can be provisioned in the Active Directory by ITIM. Presumably a subset of these users will request z/OS DB2 services with Kerberos authentication. Because we also assume that only the Active Directory is a Kerberos Key Distribution Center (KDC), these users do not need RACF USER profiles of their own. However, there will be a need for KERBLINK mapping profiles for these users (with a one-to-one or many-to-one mapping, the latter on the basis of the Kerberos realm) and mapped-to user IDs. The mapped-to RACF user IDs can be provisioned by ITIM. However, the KERBLINK RACF profiles would have to be managed manually. Refer to “Kerberos principal name mapping” on page 106 for an explanation of the profiles in the RACF KERBLINK class of profiles.
Business Partner employees Business Partner employees are registered in an LDAP directory at the Business Partner. However, because some of them will be using the services provided in z/OS (either via Web services or HTTP requests), those employees need to be registered in the corporate z/OS LDAP as well. Note the following points: Users using Web services that are authenticated both at the Web service client and provider need to be known in the corporate z/OS LDAP user registry. Users using the pure HTTP connection are authenticated by the Corporate TAM, plus they have to be known in the Corporate z/OS LDAP directory, because it is also used as the TAM user registry.
Customers Customers in this sample are users who are neither in the Corporation or in the Business Partner organization. These users access z/OS system applications via HTTP only, and are to be authenticated using the Corporate z/OS LDAP user registry.
User registries This section summarizes the logical user registries and the underlying products used in our sample configuration to authenticate users.
222 Designing for Solution-Based Security on z/OS One user registry at the Business Partner location The user registry at the Business Partner location is an LDAP directory running on an AIX system. We used the IBM Tivoli Directory Services (ITDS) LDAP server.
Three user registries at the Corporation location We distinguish three logical user registries in the Corporation: RACF for TSO and CICS users. These are Corporate users only. z/OS LDAP for authenticating users that issue Web services or HTTP requests to z/OS. These users are: – Business Partner users known as users of the Corporate HTTP/WebSphere Application Server servers – Customers known as Corporate HTTP server users The z/OS LDAP server is set up with the TDBM or LDBM back-end (LDBM is available with the ITDS for z/OS only), and the user entries include the object classes person and inetOrgPerson. The server also runs with a GDBM back-end that provides changelog information to help trigger the synchronization of directories by ITDI. Microsoft Active Directory This is used for corporate users that use Windows workstations. Microsoft Active Directory is also a Kerberos Key Distribution Center (KDC).
Note: The choice of a user registry technology is dictated by many parameters specific to an enterprise’s technology mix and its current infrastructure and planned expansion. The way an enterprise structures and maintains organizational data also affects the decision. In many cases, LDAP technology is the best fit to meet all the requirements surfacing in today’s installations.
11.2 Dealing with multiple directories
This section discusses possible solutions for user provisioning and user registry synchronization across the sample configuration’s organizational domains.
11.2.1 User provisioning and registry synchronization
User provisioning in the Corporation is provided by an ITIM server using the flow illustrated by the numbers in Figure 11-2.
Chapter 11. Sample configuration - identity provisioning, authentication and authorization 223
Business Partner Corporation
Windows A Active Directory DB2 client Kerberos KDC Windows
Kerberos authentication LDAP User registry z/OS DDF AIX WebSphere SOAP WebSphere CICS Application DB2 Server Web service A Application Server
IPSec VPN RACF Windows Security ITDI 3 browser
RACF 1 ITIM EJBROLE
LDAP Linux authentication Linux customers ITDI
WebSEAL IBM Authentication Tivoli proxy 2 Access browser Manager z/OS LDAP User registry Windows
Hardware crypto
Figure 11-2 User provisioning and registries - synchronization
1 IBM Tivoli Identity Manager (ITIM) is used to provision all users in the corporate user registries, that is: – The Corporate z/OS LDAP user registry –RACF – Microsoft Active Directory
Using ITIM as the focal point for user provisioning allows us to maintain, at this single point of control, a view of the enterprise as an ITIM organizational tree. Its population can therefore be handled using the ITIM set of services and functions.
2 IBM Tivoli Directory Integrator (ITDI) performs the LDAP user entry and RACF USER profile password synchronization.
3 The subset of the Business Partner’s user population that needs access to the z/OS WebSphere Application Server Web services must be replicated into the corporate z/OS LDAP user registry. Because we want ITIM to permanently give a complete view of all users in the organizational tree, ITIM is actually installing any relevant updates to the Business
224 Designing for Solution-Based Security on z/OS Partner population into the z/OS LDAP. In order to do so, relevant updates are propagated from the Business Partner LDAP directory to ITIM using ITDI.
Be aware that, although we are showing two ITDI blocks in Figure 11-2 on page 224, there is only one instance of the ITDI product, actually executing here on z/OS for infrastructure simplification reasons. In the following section we provide details about the contents and synchronization requirements of the user registries.
Note also that, in our sample configuration, the Active Directory is not subject to synchronization. We made the assumption that Active Directory user entries would be synchronized, if there is a need to do so, directly by ITIM. Considering the z/OS DB2 server Kerberos authentication, we are assuming that if new Windows users are created who need access to DB2, they would appear in a specific ITIM role that would trigger the creation of Kerberos principal names in the Active Directory accounts of those users.
Our ITDI implementation: For simplicity, we do not show the TIM adapters for RACF and z/OS LDAP. Refer to “ITIM LDAP adapter” on page 216, for more information about these adapters. From a purely functional standpoint, we could avoid placing an ITDI 3 between the Business Partner directory and the Corporate ITIM, because ITIM could have potentially been connected, using an LDAP adapter, to the Business Partner directory. However, connecting the ITIM directly to the Business Partner domain could cause security concerns. We also assumed that provision should be taken in case the Business Partner were to modify the format of the LDAP entries in such a way that the processes in place in ITIM would be affected. The ITDI would then be available to reformat the LDAP data to be exploitable by ITIM. In a real-world implementation, some reformatting of the LDAP data would be necessary, anyway.
11.2.2 User registries
This section describes the contents of the user registries involved in synchronization data flows, and what the synchronization requirements are.
RACF The synchronization of RACF USER profiles and LDAP entries is achieved using the LDAP protocol. The z/OS LDAP SDBM back-end is used to access the password envelope in the RACF USER profiles for password synchronization of the LDAP user entry. RACF password enveloping is used when the user password in the LDAP directory needs to be synchronized. The z/OS LDAP GDBM back-end is used to externalize the changelog information in order for ITDI to detect changes in the RACF USER or GROUP profiles.
Corporate z/OS LDAP user registry The Corporate z/OS LDAP user registry directory information tree is organized in the following way. One subtree is for the authentication of Business Partner employees. These are the entries for the Business Partner employees that need to be authenticated by the WebSphere Application Server or HTTP servers on z/OS.
Chapter 11. Sample configuration - identity provisioning, authentication and authorization 225 Two subtrees are dedicated for Corporate users who have a USER profile in RACF but also need to be authenticated via LDAP. – User entries with native authentication; that is, users whose passwords are kept in RACF. – User entries with the userPassword attribute. The passwords of these users must be synchronized between their RACF USER profiles and their LDAP entries. One subtree for Customers who need to authenticate to Corporate HTTP servers.
All user entries in these subtrees are provisioned and managed by ITIM.
Business Partner user registry The Business Partner directory tree is organized as follows: There is one subtree for users operating only within the Business Partner organizational domain. There is one subtree for users who need to access and authenticate to Corporate servers.
11.2.3 User registries - synchronization flow
The user registry synchronization flow is illustrated by the numbers in Figure 11-3. The selection of entries to synchronize is based on the specific subtree that the entries belong to in the LDAP user registries.
226 Designing for Solution-Based Security on z/OS
Corporate z/OS LDAP user registry
Business Partner LDAP user registry BP users Provisioning/Maintenance with WAS/HTTP of BP entries Authentication subtree BP private subtree •ITDI watching changelog •ITDI access controlled by ACLs Subtree with persons authorized to 4 Customers Corporate 2
Corporate Strips out with native attributes 3 workflow authentication subtree ITDI on z/OS ITIM TDI 1 Corporate with 6 userpassword
RACF corporate •ITDI watching changelog 5 z/OS GDBM 5 Password change Password envelope Z/OS SDBM
Password 7
Figure 11-3 User registries - synchronization flow
1 The Corporate LDAP user registry and RACF contents are primed, then maintained by ITIM.
2 A change in the Business Partner user registry that affects users to be duplicated at the Corporation is detected by ITDI which is “watching” (doing a persistent search) at the Business Partner changelog (ITDS offers a changelog option identical to the GDBM back-end in z/OS). The assumption here is that we dedicate a subtree in the directory for these users to be duplicated in the z/OS LDAP. ITDI starts an AssemblyLine that will therefore select the meaningful changed entries on the basis of a specific string of attribute values in the changed entry distinguished name. This requires that the Business Partner and the Corporation agree on which attribute values designate the users to also authorize in the Corporation. The Business Partner organization can restrict the ITDI access to the LDAP directory contents using the LDAP ACLs. The ACLs apply either at the directory entry or at the attribute level.
3 The ITDI AL reformats the Business Partner LDAP entry contents and strips out attributes that are not meaningful to the Corporation, then triggers the execution of a workflow in ITIM.
4 The execution of the ITIM workflow eventually results in creating, altering, or deleting the Corporate z/OS LDAP entry for the corresponding Business Partner user.
Chapter 11. Sample configuration - identity provisioning, authentication and authorization 227 5 Changing the password of some RACF users must trigger a password synchronization into their z/OS LDAP entry. We are assuming that the z/OS LDAP GDBM (also known as the changelog directory) is in operation, and that the NOTIFY.LDAP.USER profile has been defined in the RACFEVNT class of profile. This profile acts as a system-level switch to have all changes to USER profiles reflected in the GDBM directory.
ITDI is performing a persistent search against the z/OS LDAP GDBM directory and detects the change.
The users with a password to be provided to ITDI should be in the access list, with a READ access mode permission, of the PASSWORD.ENVELOPE profile in the RACFEVNT class of profiles in RACF. Adding the relevant users in this access list is a manual administrative process.
For complete details about the Password Enveloping process and its setup, refer to z/OS Security Server RACF Security Administrator’s Guide, SA22-7683.
6 An ITDI AL manages to get the password envelope, to satisfy both of the following conditions: – ITDI has an RSA key pair, and the z/OS RACF administrator managed to get the ITDI certificate and connect it to the IRR.PWENV.KEYRING key ring in RACF. – ITDI has been given a RACF user ID that is permitted READ access to the IRR.RADMIN.EXTRACT.PWENV in the FACILITY class of RACF profiles. And the user ID and password have been successfully used to bind to the SDBM back-end in order to get the Password Envelope.
The ITDI AL proceeds with the unwrapping and decryption of the Password Envelope, and retrieves the user’s new RACF password.
7 The retrieved new password is then installed via an ldapmodify operation executed by the ITDI AL against the target user entry in the Corporate z/OS LDAP directory.
Important: The new LDAP user password can be kept encrypted in the directory user entry if this option has been selected at the LDAP server. However, the retrieved new RACF password is sent in clear from ITDI to the target LDAP entry. It is therefore mandatory to protect the communication with SSL/TLS.
11.3 Variations on identification and authorization
This section discusses the identification and authorization mechanisms we selected for the WebSphere Application Server for z/OS in the Corporation z/OS.
WebSphere Application Server and J2EE security at a general level are covered in Chapter 9, “WebSphere Application Server for z/OS and Web Services Security basics” on page 155.
11.3.1 WebSphere Application Server identification and authentication with LDAP
In our sample configuration, we decided to use LDAP as the WebSphere Application Server user registry. All users who have to authenticate via the WebSphere Application Server container must therefore have an LDAP entry in the user registry. The user registry in our
228 Designing for Solution-Based Security on z/OS case is a directory tree in the TDBM or LDBM z/OS LDAP back-end. Here is an example of such an LDAP entry: distinguished name: uid=wastom,ou=wasusers,ou=corptdbm,o=itso,c=us uid=wastom objectclass=inetOrgPerson objectclass=organizationalPerson objectclass=top sn=tommy cn=tom password=xxxx
As explained in 6.2, “Using the z/OS LDAP directory as a user registry” on page 97, the user can logon with the user ID “tommy” and a password (or, a SOAP message header can contain a security token with this userID and password). The WebSphere Application Server container then searches, via its embedded LDAP client, the LDAP user registry for an entry containing “tommy” as a short name (sn). It will find, in this example, the entry with the distinguished name uid=wastom,ou=wasusers,ou=corptdbm,o=itso,c=us.
The WebSphere Application Server then performs an authenticated bind against the LDAP server, using this distinguished name and the password provided by the user. The password will be compared by the LDAP server to the userPassword value in the LDAP entry.
As an alternative, the z/OS LDAP native authentication facility can be used with the TDBM or LDBM back-end. The LDAP server will not compare the user password with the password in the entry, but instead will ask RACF to verify the user ID and password, so the user ID that RACF should verify is either the uid value, or the ibm-nativeId value. (The LDAP entry should not contain the userPassword attribute in order for the native authentication to work.)
Attention: The WebSphere Application Server ldapsearch filter for user authentication searches by default for the value of the uid attribute. It requires you to modify the default filter to search on an sn value. The same reasoning applies as well for groups, because the group default search filter might not match the attributes (and object classes) intended to be used by the installation.
The design of the LDAP user registry directory tree is of prime importance because its contents must accurately represent user and group organizational structure. However, it must also be done with search efficiency and with planned future growth in mind.
Individual user entries that are alike and user group entries that are alike are also built in the LDAP directory tree. Here is a typical group entry: distinguished name: cn=groupcorp3,ou=groups,ou=corptdbm,o=itso,c=us objectclass=groupOfNames objectclass=top cn=groupcorp3 member= uid=initial,c=us member= uid=wastom,ou=wasusers,ou=corptdbm,o=itso,c=us member= ...
The member attribute in the groupOfNames object class contains the distinguished name of a member of the group. The LDAP server automatically collects all the groups that a user is in when the user performs a successful LDAP bind.
Chapter 11. Sample configuration - identity provisioning, authentication and authorization 229
Note: Many products also need to define “technical” users in a user registry. These users are identities used by the product itself, for example, to access the LDAP directory for its
own, internal needs. WebSphere Application Server needs such technical users to be defined as described by the instructions in the installation manual.
11.3.2 WebSphere Application Server authorization
For background information about WebSphere Application Server authorization, refer to 9.3, “WebSphere Application Server authorization mechanisms” on page 167.
A J2EE role-based authorization mechanism must be selected during the setup of WebSphere Application Server. We experimented with both z/OS System Authorization Facility (SAF) authorization (which invokes RACF), and the Java Authorization Contract for Container (JACC) authorization (which calls the Tivoli Access Manager for authorization checking). In both cases, we kept LDAP as the WebSphere Application Server user registry.
SAF authorization As explained in Chapter 9, “WebSphere Application Server for z/OS and Web Services Security basics” on page 155, when SAF authorization is enabled, RACF uses the EJBROLE profiles definitions and their access list to determine if the user ID passed by WebSphere Application Server is in the required role.
Actually, the RACF user ID in this case is a JAAS principal (in Java terminology), itself in a JAAS “subject”. This can be thought of as a WebSphere Application Server container-level security context (such as the ACEE is in z/OS).
Using SAF authorization with LDAP authentication, however, means that the JAAS principal (that is, the authenticated user ID) is now an X.500 directory distinguished name and cannot therefore be passed as is to the SAF; a mapping to a RACF user ID is required.
The WebSphere Application Server infrastructure allows you to do the mapping at logging time by adding a specific JAAS module that performs this mapping in the so-called “JAAS login configurations”. The login configurations to consider are WEB_INBOUND (which handles logins for Web application requests, including servlets and JavaServer Pages) files; RMI_INBOUND (which handles logins for inbound RMI/IIOP requests to execute EJBs); and DEFAULT (any other logins for inbound requests).
A sample mapping module is available on the WebSphere Info Center under the name of “com.ibm.websphere.security.SampleSAFMappingModule”.
When the mapping has been performed, the mapped-to RACFuserID is preserved and can be retrieved when using SAF authorization.
JAAC TAM provider authorization This section provides a high level representation of J2EE JACC role-based authorization with the default JACC provider that is provided by WebSphere Application Server. This JACC provider supports Tivoli Access Manager as the authorization provider. The numbers in Figure 11-4 illustrate the authorization process flow.
230 Designing for Solution-Based Security on z/OS
Business Partner Corporation
browser WAS Web Service Web Web services SOAP implementation app requestor 7 Request to Web Container EJB Container Web services JAAS Login authentication Module connector or servlet EJB TAI
BP JAAC LDAP 6
ITDI z/OS LDAP (TDBM or LDBM) 8 browser LDAP users Authorization …. requests ITIM LDAP groups cn=BP_acme_roleA cn=BP_acme_roleB 1 cn=BP_acme_roleC
4 TAM Authorization 5 database ACLs 4 3 webSEAL URL WAS– cn=BP_acme_roleA cn=BP_ACME_roleB cn=BP_ACME_roleC
Role A – cn=BP_acme_roleA 2 Role B – cn=BP_ACME_roleB Role C – cn=BP_ACME_roleC
Figure 11-4 Using a JACC provider with TAM
1 As explained in “Corporate z/OS LDAP user registry” on page 225, the z/OS LDAP user registry contains a subtree with user entries pertaining to the Business Partner users that can access the Corporation WebSphere Application Server using plain HTTP.
Any update to the Business Partner user registry that affects these users is detected by ITDI and propagated to TIM. TIM then executes whatever actions need to be performed with the corresponding z/OS LDAP entries.
Figure 11-3 shows the z/OS LDAP user registry users and groups. As with any user registry, it is good practice to assign users to groups in order to manage privileges at the group level. We chose a naming convention for the distinguished names of the groups where the cn attribute value refers to the J2EE role that this group should be in. For instance, the group with the distinguished name cn=BP_acme_roleA (we are just showing the first attribute of the distinguished name here) has members that should be granted J2EE role A privileges. However, this convention requires that the security administrator and the application deployer agree on the J2EE roles name.
2 The Tivoli Access Manager security utility that is embedded within WebSphere Application Server is used to add the security policy information in the TAM authorization database when the application is deployed. TAM creates objects, ACLs, servers, users, and groups from the
Chapter 11. Sample configuration - identity provisioning, authentication and authorization 231 application deployment information. Figure 11-4 shows that TAM has set ACLs so that the user group cn=BP_acme_roleA is granted J2EE role A.
The TAM administrator granted the same user groups access to the z/OS WebSphere Application Server URL.
3 A Business Partner user sends an HTTP request to the z/OS WebSphere Application Server. Because of the established TCP/IP routing, the request is intercepted by the Corporation WebSEAL reverse proxy, which then proceeds with user authentication.
4 Because TAM has been set up to use the z/OS LDAP user registry, WebSEAL uses the same registry to authenticate the user and gathers the information that the user is a member of group cn=BP_acme_roleA. WebSEAL verifies with TAM that the security policy in the authorization database allows the user, or a group that the user is a member of, to access the WebSphere Application Server URL.
5 WebSEAL forwards the request to WebSphere Application Server and provides the identity information, and the authentication information if required, to a TAI or JAAS login module, depending on the WebSphere Application Server configuration setup.
6 Again depending on the setup, a JAAS login module may proceed with a second authentication, still using the z/OS LDAP user registry.
7 A Java subject (that is, a Java security context) has been built for the request that the J2EE containers will use to determine whether the user is in the required role. The Java subject also names the groups that the user is a member of.
8 Because the WebSphere Application Server containers have been set up to use the JAAC provider for authorization, WebSphere Application Server sends a request to TAM, using the aznAPI, to verify whether the user is in the role required at deployment time in order for the application to be executed.
For performance reasons, WebSphere Application Server, like other implementations of TAM resource managers, maintains a cached image of the authorization database. This image is refreshed on a signal that TAM sends when modifications are made to the master instance of the authorization database.
232 Designing for Solution-Based Security on z/OS Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this book.
IBM Redbooks
For information about ordering these publications, see “How to get Redbooks” on page 234. Note that some of the documents referenced here may be available in softcopy only. zSeries Crypto Guide Update, SG24-6870 IBM eServer zSeries 990 (z990) Cryptography Implementation, SG24-7070 z9-109 Crypto and TKE V5 Update, SG24-7123 OS/390 Security Server 1999 Updates Technical Presentation Guide, SG24-5627 OS/390 Security Server 1999 Updates: Installation Guide, SG24-5629 Implementing PKI Services on z/OS, SG24-6968 Putting the Latest z/OS Security Features to Work, SG24-6540 z/OS 1.6 Security Services Update, SG24-6448 Understanding LDAP - Design and Implementation, SG24-4986 Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-6014 Robust Data Synchronization with IBM Tivoli Directory Integrator, SG24-6164 Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996 z/OS UNIX Security Fundamentals, REDP-4193
Other publications
These publications are also relevant as further information sources: z/OS Security Server RACF Callable Services, SA22-7691-11 z/OS Security Server RACF Auditor’s Guide, SA22-7684-08 z/OS Security Server RACF Security Administrator’s Guide, SA22-7683-11 IBM Tivoli Directory Server Administration and Use, for z/OS, SC23-5191 z/OS Integrated Security Services Enterprise Identity Mapping (EIM) User Guide and Reference, SA22-7875 z/Architecture Principles of Operation, SA22-7832 z/OS Communications Server IP Configuration Guide, SC31-8775 z/OS and z/OS.e Planning for Installations, GA22-7504 z/VM CP Planning and Administration, SC24-6083 z/VM General Information, GC24-6095 z/OS Security Server RACF Macros and Interfaces, SA22-7682
© Copyright IBM Corp. 2008. All rights reserved. 233 WebSphere Application Server for z/OS, Securing Applications and Their Environment, SA22-7961 z/OS Cryptographic Services PKI Services Guide and Reference, SA22-7693 z/OS Integrated Security Services Network Authentication Service Administration, SC24-5926
Online resources
Pointers to the formal security evaluations of IBM products can be found at: http://www.ibm.com/security/standards/st_evaluations.shtml
The details of getting Linux certified against ISO 15408 are available at: http://www.ibm.com/security/standards/st_evaluations.shtml
How to get Redbooks
You can search for, view, or download Redbooks, Redpapers, Technotes, draft publications and Additional materials, as well as order hardcopy Redbooks, at this Web site: ibm.com/redbooks
Help from IBM
IBM Support and downloads ibm.com/support
IBM Global Services ibm.com/services
234 Designing for Solution-Based Security on z/OS Index
authorityKeyIdentifier 49 Symbols authorization database 196 _initACEE 105 authorization engine 194 authorized program 37 A Authorized Program Facility (APF) 18, 37 abandon 95 azn_creds_delet 203 acceleration, RSA 86 azn_decision_access_allowed 203 access control 6 azn_id_get_creds 203 Access Control Environment Element 45 aznAccess 203 Access Control List 94, 104 aznAPI 171, 195 Access Manager aznAPI. 11 ... for Business Integration 200 aznCreds 203 pdadmin 197 Policy Proxy Server 197 B Policy Server 197 basicConstraints 49 Trust Association Interceptor 199 BBO.SYNC 159, 167 Web Portal Manager 197 BBO.TRUSTEDAPPS 160 Access Manager Business Integration Host Edition 202 bind 95, 100 Access Policy 3 BIND 9 131 accessGroup 99 binding 177 accessRole 99 biometrics 121 account 210 BSM Control File 22 Accountability Policy 3 ACEE 45–46, 230 ACF2 44 C ACL 94, 104, 195, 227 CA 116 add 95 Callback 161 ADDUSER 58 CallbackHandler 161 Advanced Encryption Standard 9 Candidate-list 83 AES 9 CAPP 17 AIX 198, 205, 215 CARS 200 ALL 53 CBIND 159 ALTER 47, 53 CCA 27 ALTUSER 58 CCF 80 ALWAYS 54 CDSA 28, 85 AMBIHE 202 CERT 131 anonymous 2 Certificate Authority 28, 116 AP 83 certificate expiration 118 Apache Web Server 198 certificate map mode 173 APDEDICATED 88 Certificate Name Filtering 46 APF (Authorized Program Facility) 19, 37–38 certificate revocation 118 APPC 215 Certificate Revocation List (CRL) 118 APPLDATA 64, 105–106, 170 Certificate Revocation Lists (CRLs) 28 application layer firewall 126 CEX2A 82 APVIRTUAL 88 CEX2C 79 ASIS 188 Change Log notification 62 AssemblyLine 207, 209, 227 changelog 227 asserted identity 109 checksum 7 Asset Classification Policy 3 Circuit level firewall 126 AT-TLS 36, 132 CKDS 84 auditing 7, 38, 53 Common Auditing and Reporting Services 200 AUDITOR 44, 55 Common Criteria 16 auditor 54 Common Cryptographic Architecture (CCA) 85 authentication 6, 45 commonName 92 Authentication Server 112 Communications Server Security Level 3 37
© Copyright IBM Corp. 2008. All rights reserved. 235 compare 95 DIT 93 CONNECT 58 DMZ 128–129, 221 CONTROL 47, 53 DOMAIN 88 Control Program 19 domain 21, 83 Controlled Access Protection Profil 17 DSA 46, 120 controlled network 128 DSMON 51 controlled zone 127 DUKPT 81 countermeasures 4 dynamic packet filter firewall 126 CP 19 CP Assist for Cryptographic Functions 79 CPACF 79–80, 86 E CRAM-MD5 96, 98 EAL 17 credential propagation 109 EAR 168 CRL 28, 117, 180 EIM 30, 106 CRT 82 EIM Domain Controller 30, 107 crypt() 98 EJB method permission 164 CRYPTO 88 EJBROLE 50, 65, 168–169, 221, 230 Crypto Express 2 79 EMV 2000 81 cryptographic encryption 7 coprocessor 21 End-to-End Accountability 10, 67 function support 80 Enterprise Identity Mapping 30, 106 processors 80 Enterprise System Architecture 15 Cryptographic Key Data Set 84 ESM 22 CryptoVSE API 86 Evaluation Assurance Level 17 CSIv2 158 Event Handler 205 CSNDPKD 82 EXECUTE 47 CSNDPKE 82 EXOP 34, 59 custom user registry 163, 173 extended attribute 38 external controlled zone 127 External Security Manager 22, 41 D external zone 127 DAC 48 EZB.NETACCESS 133 data confidentiality 7 Data Encryption Standard 9 data integrity 7 F Data Security Monitor 51 facility name 39 DATAGRAMFWD 131 FAILURES 53, 55 DEFAULT 55, 188 FC 3863 80 DEFAULT login configuration 161 federated repositories 163 delegation 6, 109, 115, 121 File Owner auditing flags 55 delete 95 File Security Packet 42 demilitarized zone (DMZ) 127 FIPS 140-2 80 Denial of Service 124 firewall 125, 129 multiple packet DoS 124 firewall technologies 29 single packet DoS 124 Five-year PKI intermediate CA server certificate 119 deployment descriptor 177 Five-year PKI IPSEC server (firewall) certificate 119 DES 9, 81 Five-year PKI SSL server certificate 119 description 92 FSOBJ 55 DFSMS 48 FSP 42, 55 DFSORT ICETOOL 52 FSSEC 56 DIAGNOSE 21 FTP 36, 114, 131 DIGEST-MD5 96, 98 digital certificate 42–43, 46 G DIGTCERT 49, 105 GDBM 33, 59, 101, 217, 225, 227 DIGTCRIT 49, 106 GEJBROLE 168, 221 DIGTNMAP 49, 106 general instructions 14 DIGTRING 49 Generalized Security Services API (GSS-API) 29 DIRACC 55 getCallerPrincipal 169 DIRSRCH 55 getUserPrincipal 169 Discretionary Access Control 48 Global Access Checking Table 51 Distinguished Encoding Rules (DER) 65
236 Designing for Solution-Based Security on z/OS group filter 173 intrusion 124 group ID map 173 Intrusion Detection Services 132 group member ID map 173 IP datagram 124 GROUP profile 42 IP Filtering 132, 221 groupOfNames 94, 97, 99 IPCOBJ 56 groupOfUniqueNames 97, 99 IPSec 9, 132, 221 groupOfURLs 99 IRR.ADMIN.EXTRACT.PWENV 64 group-OPERATIONS 54 IRR.LDAP.REMOTE.AUTH 66 group-SPECIAL 54 IRR.RAUDITX 66 GSS-API 29, 115 IRRADU00 56 IRRPassTicket 58 isCallerInRole 169 H ISO 15408 16 hardware cryptography 24 ISO 7498-2 6 hardware interruption 14 issuerAltName 49 hash value 7 isUserInRole 169 HCD backend 32 ITDI 44, 64, 191, 193, 204, 224 HCR7740 28 ITDI connector 207 HCR7750 28, 86 ITDI event handler 208 HIPAA 75 ITDI function component 208 homeDirectory 96 ITDI hook 208 hostIDMap 119 ITDI parser 208 HP Unix 198, 205 ITDI script 208 HP-UX 215 ITDS 29, 31, 191, 193, 223 HTTP 125, 157 ITIM 210, 225 HTTPS 125 ITSEC 16 hypervisor 19 IUCV connections 21
I J i5/OS 206 J2EE 25, 42, 50, 156, 175 IBM 4753 81 J2EE roles 167 IBM Common Cryptography Architecture 27 JAAS 160 IBM DataPower 187 JAAS login module 161 IBM HTTP Server 198 JAAS principal 170, 230 IBM Ported Tools for z/OS 25 JAAS subject 161 IBM SDK 85 JACC 168, 170, 175, 181, 221, 230 IBM Tivoli Directory Integrator 101 JAR 168 IBM Tivoli Directory Server for z/OS 29 Java 25, 44, 58, 88 ibm-dynamicGroup 99 Java Authentication and Authorization Services 160 IBMJCECCA 159, 185 Java Authorization Contract for Containers 170 IBMJSSE2 185 Java Contract for Containers 168 ibm-nativeAuthentication 99 Java cryptographic service providers 85 ibm-nativeId 98, 229 Java Message Service 158 ibm-nestedGroup 100 Java thread identity 164 IBMPKCS11Impl 88 JAX-RPC 177 IBMRRAP 175, 189 JAX-WS 177 ibm-staticGroup 99 JCA 157 ICHPWX11 45 JCECCAKS 185 ICSF 27, 49, 84 JCECCARACFKS 185 ICTX 49, 59, 65, 68 JCEKS 185 identification 6, 45 JDBC 166, 207 identity assertion 6, 109, 165, 182 JDK 58 identity mapping 105 JMS 157–158, 178, 180 IDS 36, 132, 221 JMX 206 IETF PKIX standards 117, 120 JSec 58 Image profile 83 JSP 169 inetOrgPerson 93, 97–98 junction 199 Integrated Cryptographic Service Facility 27 JVM 157 Intel Common Data Security Architecture (CDSA) 28 Internet threats 125
Index 237 K Microsoft Active Directory 114, 197, 221, 223 KDC 12, 111, 222 Microsoft Active Directory Application Mode 197 Microsoft.NET 175 KERB segment 49, 106, 113 Kerberos 8, 26, 29, 42–43, 49, 104–105, 111 minidisks 20 Kerberos forwardable tickets 115 MIT Kerberos V5 115 Kerberos Key Distribution Center 12, 107 MLS 42, 48, 52 Kerberos pre-authentication 116 modify 95 Kerberos Realm 111 modifyDN 95 KERBLINK 47, 106, 113, 222 MRA 17 Key Distribution Center 26, 30 MSA 80 key-controlled protection 15 Multilevel Security 42 KeyUsage 49 Multiple Virtual Storage 18 krbprincipalname 105 mutual recognition arrangement 17 MVS 18 L Labelled Security Protection Profile 17 N Language Environment 44 NAT 125 LDAP 8, 91, 120–121 national characters 45 LDAP adapter 216 Native Authentication 33 LDAP attribute 92 native authentication 209 LDAP Data Interchange Format 94 NETACCESS 133 LDAP Directory Information Tree 93 network LDAP Directory Server 29 zones 128 LDAP entry 93 Network Address Translation 125 LDAP entry Distinguished Name 94 Network Authentication Service 29 LDAP Native Authentication 98–99 Network Level Security 25 LDAP object class 92 network model 126 LDAP replication 34, 101 network zone LDAP schema 92 controlled 128 LDAP suffix 94 restricted 128 LDAP user registry 91 secured 129 ldapadd 60 uncontrolled 128 ldapdelete 60 NEVER 55 ldapmodify 60 NFS 114 ldapsearch 60 NOFAIL 188 LDBM 33, 98, 209, 229 NONE 47, 53, 188 LDIF 94 NOPASSWORD 131 libica 87 NOTIFY.LDAP.CONNEC 63 Linux 19, 23, 198, 205, 215 NOTIFY.LDAP.GROUP 63 LIPKEY 30 NOTIFY.LDAP.USER 228 LoginContext 161 NOUAUDIT 54 LoginModule 161 Novell eDirectory 197 loginShell 96 n-year PKI browser certificate for extensions demonstra- LOGOPTIONS 54 tion 119 Lotus Domino 160, 197 low-address protection 15 O LPA 38 OAM 201 LSPP 17 OASIS 176 LTPA 199 Object Authority Manager 201 LTPA_WEB 161 object reuse 16 OCEP 28 M OCSF 28, 85 MAC 48 OCSP 120–121 Mandatory Access Control 48 ODBC 204 Master Key 80, 83 OMPROUTE 36 MD5 9, 98 One-year PKI S/MIME browser certificate 119 ME 82 One-year PKI SSL browser certificate 119 member 97 One-year SAF browser certificate 119 Message Security Assist 80 One-year SAF server certificate 119
238 Designing for Solution-Based Security on z/OS Online Certificate Status Protocol 120 posixGroup 96 Online Certificate Status Protocol (OCSP) 28 PPT 51 On-line list 83 PR/SM 15, 18 Open Cryptographic Enhanced Plug-in (OCEP) 28 priority code 39 Open Cryptographic Service Facility 28 Private Key Data Set 84 Open Shortest Path First (OSPF) 36 PrivateCredentialPermission 161 OpenSSH 25 Privilege Policy 3 OpenSSH for z/OS 37 privileged instructions 14 OPERATIONS 54 PROCACT 56 organizational tree 211 PROCAT 56 organizationalPerson 93 PROCESS 56 OS thread identity 164, 166 Program Control 131 OS/390 18, 41 Program Property Table 51 OSPF 36 programmatic security 169 OSPF MD5 36 Protected Object Namespace 195 Protected Object Policy 195 Pseudo Random Number Generator 81 P Public Key Algorithm 81 packet filter firewall 126 Public Key Infrastructure 8, 116 page protection 15 PAGENT 135 PAM 96, 160 Q PassTicket 42, 45 Queue number 83 PassTicket generator 45 password 42–43, 45 Password Enveloping 59 R password phrase 42, 45 R_auditx 52, 66 PASSWORD.ENVELOPE 64, 228 R_cacheserv 203 PCICA 81 R_GenSec 29 PCICC 80 R_gensec 58 PCI-X 80 R_proxyserv 203 pdacld 203 R_tickerserv 58 pdadmin 197 R_usermap 106 PDAS 203 RACDCERT 49 persistent search 228 RACF 28, 41 person 92 RACF access list 104 PKCS#11 85, 88 RACF adapter 215 PKCS#12 49 RACF Auditor auditing flags 55 PKCS#7 49, 63, 180 RACF Authorized Caller Table 51 PKDS 49, 84, 121, 185 RACF Callable Services 44 PKI 116 RACF Identity Cache 64 PKITP 28 RACF key ring 120, 159 PKIX 8 RACF Remote Authorization Provider 175 Platform Level Security 25 RACF Remote Sharing Facility 44 PlatformAccessControl 58 RACFEVNT 228 PlatformAccessLevel 58 racfPasswordEnvelope 64 PlatformReturned 58 RACROUTE 22, 44 PlatformSecurityServer 58 RACROUTE REQUEST=AUTH 65 PlatformThread 58 RACROUTE REQUEST=VERIFY 69 PlatformUser 58 RDN 94 Pluggable Authentication Module 96 READ 47–48, 53–54 pluggable mapping module 174 REALM 110, 113 Policy Agent 135 reason code 43 Policy Director Authorization Services 203 Redbooks Web site 234 policy domain 4 Contact us xiii policy enforcer 196 reference number 69 Policy Proxy Server 197 Regulatory Compliance Policy 3 Policy Server 197 relative distinguished name 94 PORT 134 remote auditing 31 PORTRANGE 134 remote authorization 31, 64 posixAccount 96 report writer 52
Index 239 resource manager 43, 198 SERVER 159 Responsibility Policy 3 servlet 169 restricted 127 SETROPTS 52 restricted network 128 SETROPTS LOGOPTIONS 56 restricted zone 127 SHA 9, 80, 98 RESTRICTLOWPORTS 134 SHA-256 80 retained key support 81 SIE 19 return code 43 SIEM 73, 192 reverse proxy 165, 198 Simple Authentication and Security Layer 96 RFC 1510 8 simple bind 95 RFC 1823 8 Simple Certificate Enrolment Protocol 120 RFC 2025 30 Single Sign-On 199 RFC 2246 8 SKRBKDC 113 RFC 2251 8 smart card 121 RFC 2328 36 SMF 51–52 RFC 2401 9 SMF Data Unload Utility 56 RFC 2410 9 SMF record type 109 39 RFC 2459 8 SMF Type 80 52 RFC 3377 8 SMF type 80 188–189 RMF backend 33 SMF Type 83 53 RMI/IIOP 157–158, 178, 180, 230 SMF type 83 189 RMI_BOUND 174 SMF type-83 100 RMI_INBOUND 161, 230 SMTP 73 RMI_OUTBOUND 161 sname 105 router 126 SNMP 73, 206 RRSF 44 SNMPv3 36 RSA 9, 46, 81, 120 SOA 5, 192, 219 rshd 36, 114 SOAP 157, 176, 180, 186 RunAs identity 164, 170 SOX 75 RVARY 52 SPECIAL 54 SPKM-3 30, 105, 110 SQL Injection 186 S SSH 37 SAF 44 SSL 8, 80 SAF classes 58 SSL Daemon 87 SAF-based local registry 163 SSL for VSE API 87 SAML 180 SSL transactions 82 SASL 96 SSL/TLS 104–105 SCEP 120 ST 17 SDBM 29, 33, 44, 49, 59, 97, 100, 209, 225 stack hardening 130 search 95 standards 7 SECLABEL 48, 54 Start Interpretive Execution 15 Secure Socket Layer 8 stateful Secure Socket Layer (SSL) 28 inspection 126 secured network 129 Statement of Integrity 18, 21 secured zone 127 storage protection 15 security subjectAltName 49 policy 129 subjectKeyIdentifier 49 Security Architecture 4 SUCCESS 53 Security Assertion Markup Language 180 SUCCESSES 55 Security Information and Event Managemen 73 Sun Java System Directory Server 197 security island 110 Sun Java System Web Server 198 security label 42 Sun Solaris 198, 206 Security level 3 36 surName 92 Security Server 28 SWAM 160, 162 Security Target 17 Sync To OS Thread 167 seeAlso 92 SYS1.LINKLIB 38 sendmail 36 SYS1.SVCLIB 38 SERVAUTH 48, 133 syslogd 39 NETACCESS 133 System Authorization Facility 44 PORTACCESS 134
240 Designing for Solution-Based Security on z/OS System Integrity 18 uidNumber 96 System SSL 28, 85 unbind 95, 100 uncontrolled network 128 uncontrolled zone 127 T uniqueMember 97 TAI 165–166, 179, 199 UNIX 198 TAM 171, 191–192, 194 UPDATE 47–48, 53–54 TAM E-SSO 194 user filter 173 TAM identity 172 user ID map 173 TAM JACC Provider 172 user identity 104 TAM Java Runtime 172 USER profile 42 TAMBI 194, 200 user registry 108 TAMeb 194, 198 username token 182 TAMOS 194 userPassword 64, 92 Target of Evaluation 17 userPassword encryption 98 TCIM 192 TCPIP.PROFILE 133 TCSEC 16 V TDBM 33, 98, 209, 229 Virtual Private Network 126 TelephoneNumber 92 VPN 80, 126 telnet 36, 114 VSE Control File 22 TFIM 191–192 TGS 113 Threat Assessment Policy 3 W Ticket Granting Server 112 WAR 168 TIM 191, 193 Web Portal Manager 197 Tivoli Access Manager 191–192, 194, 221 Web Services 25 Tivoli Compliance Insight Manager 75 Web Services Description Language 177 Tivoli Directory Integrator 191, 193, 204 WEB_INBOUND 162, 174, 230 Tivoli Directory Server 191, 193 WebSEAL 160, 166, 172, 198–199, 221, 232 Tivoli Federated Identity Manager 191–192 junction 199 Tivoli Identity Manager 191, 193, 210 Trust Association Interceptor 199 Tivoli Identity Manager role 212 WebSEAL SSO 172 Tivoli Security Compliance Manager 191–192 WebSphere Application Server 50, 155 Tivoli Security Operations Manager 73, 191–192 administration 171 TKDS 85 authorization 167 TLS 8 component 168 TN3270 36 credential 172 TOE 17 deployment 166 Token Key Data Set (TKDS) 85 PDPrincipal 166 Top Secret 44 policy 166 Transaction Level Security 25 WebSphere Application Server 6 165 Transport Layer Security (TLS) 28 WebSphere MQ 200 trust 4 Windows 198, 206, 215 Trust Association Interceptor 165, 199 Windows XP 114 Trust Policy 3, 28 workflow 213 Trusted Proxy Server 165 WS-Authorization 181 Trusted Third Party 107 WSDL 177, 186 TSOM 191–192 WS-Privacy 181 TTP 107 WSS 176 Two-year PKI Authenticode 119 WS-SecureConversation 181 Two-year PKI browser certificate for authenticating to WS-SecurityPolicy 181 z/OS 119 WS-Trust 181 Two-year PKI Windows logon certificate 119 X U X.500 8 UACC 47, 51 X.500 directory distinguished name 230 UAUDIT 54 X.500 distinguished name 104 UDX 81–82 X.500 name 56 uid 97, 105, 229 X.500 subject’s name 105
Index 241 X.509 8, 42, 46, 49 X.509 token 182 X.509 V2 Certificate Revocation List 117 X.509 V3 certificate 116 X.509 V3 digital certificate 119 XML 52 XML Denial of Service 186 XML encapsulation 186 XML-formatted output 57
Z z/OS 206 z/OS Cryptographic Services 27 z/OS IBM Ported Tools 37 z/OS Identity Cache 30 z/OS Integrated Security Services 29 z/OS Integrated Security Services LDAP server 31 z/OS LDAP 26 z/OS LDAP client 31 z/OS PKI Services 25, 28 z/OS Security Level 3 35 z/OS Security Server 28 z/OS UNIX 55 z/OS UNIX System Services 52 z/OS V1R9 85 z/VM 15, 17, 19 z/VM directory 20 z/VSE 22 z90crypt 87 zcrypt 87 zSecure 191–192 zSecure Admin 70 zSecure Alert 77 zSecure Audit 76 zSecure CICS Toolkit 72 zSecure Command Verifier 78 zSecure Visual 71
242 Designing for Solution-Based Security on z/OS
Designing for Solution-Based Security on z/OS
Designing for Solution-Based Security on z/OS
Designing for Solution-Based Security on z/OS
Designing for Solution-Based Security on z/OS (0.2”spine) 0.17”<->0.473” 90<->249 pages
Designing for Solution-Based Security on z/OS
Designing for Solution-Based Security on z/OS
Back cover ® Designing for
Solution-Based Security on z/OS ®
A comprehensive This IBM Redbooks publication provides solution designers and INTERNATIONAL overview of architects with a comprehensive view of the security services they can exploit on z/OS, whether their application is hosted by TECHNICAL z/OS-provided z/OS or by another platform. It also discusses, at a high level, the SUPPORT security services Tivoli products that team with mainframe security services to ORGANIZATION provide flexible and extensible security architectures that fit On A discussion of z/OS Demand infrastructure requirements, because implementing security, Tivoli optimum solution-based security requires extensive knowledge products, and On of what security services and APIs provide on the platforms for BUILDING TECHNICAL which you are developing the solution. Demand INFORMATION BASED ON The book briefly describes data processing security concepts, PRACTICAL EXPERIENCE with a focus on the problems that enterprises face today because Expert considerations of the heterogeneous nature of their platforms and technologies, IBM Redbooks are developed on implementation and the requirement to progress towards an On Demand by the IBM International and use environment. Next, it explains the security services and APIs that Technical Support are provided on z/OS, with respect to the security concepts they Organization. Experts from IBM, Customers and Partners implement and their seamless integration into distributed from around the world create environments, as building blocks for optimal solution-based timely technical information security. This analysis is examined from the perspective of both based on realistic scenarios. z/OS solutions and non-z/OS hosted solutions, because non-z/OS Specific recommendations hosted solutions can exploit the remote security services that are provided to help you implement IT solutions more z/OS offers. High level explanations and exploitation effectively in your considerations are provided for z/OS RACF, LDAP server, environment. Kerberos and PKI support, z/OS Communications Server-specific features (such as embedded IP filtering, IPSec VPNs, and application-transparent TLS), and many other features. For more information: ibm.com/redbooks
SG24-7344-00 ISBN 0738431486