designing for solution-based security on z/os · designing for solution-based security on z/os...

ibm.com/redbooks

Front cover

Designing for Solution-Based Security on z/OS

Patrick KappelerRama Ayyar

Christian ChateauvieuxArnauld DespretsGillian GainsfordPedro Siena Neto

Alain RoessleMohinze Tidjani

Mark Womack

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

http://www.redbooks.ibm.com/


International Technical Support Organization


October 2008

SG24-7344-00

© 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 ScheduleContract with IBM Corp.

First Edition (October 2008)

This edition applies to Version 1, Release 9 of z/OS (product number 5694-A01).

Note: Before using this information and the product it supports, read the information in “Notices” on page ix.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiThe team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Chapter 1. Some security basics - today’s challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Heterogeneity everywhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Security challenges in today’s installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 More on installation security policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.2 A word about security architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 The end-to-end security challenges in the on-demand world . . . . . . . . . . . . . . . . . . . . . 41.3.1 The concepts of SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.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 . . . . . . . . . . . . . . . . . . . . . 51.4.1 A high-level definition of what the required security services are . . . . . . . . . . . . . . 61.4.2 An important set of universally adopted standards . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5 Today’s obstacles to the implementation of end-to-end security . . . . . . . . . . . . . . . . . . 91.5.1 Islands of non-standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5.2 The end-to-end accountability problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.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 . . . . . . . . . . . . . . . . . . . . . . . 132.1 The heritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.1 Synergy between hardware and software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Virtualized environments and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Security and virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.2 Certification of virtualized environment security . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3 z/VM certification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.4 PR/SM certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 The System z operating system security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.1 z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.2 z/VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.3 z/VSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.4 Linux for System z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 3. z/OS security services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 The overall views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 z/OS security services and APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 z/OS Cryptographic Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.2 z/OS Integrated Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.3 IBM Tivoli Directory Server for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.4 z/OS Security Level 3 optional feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.5 Security functions in the z/OS Communications Server . . . . . . . . . . . . . . . . . . . . 363.2.6 Communications Server Security Level 3 optional feature . . . . . . . . . . . . . . . . . . 373.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 . . . . . . . . . . . . . . . . . . . . . . 373.4 A word about auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4.1 RACF auditing data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.4.2 Syslog daemon (syslogd) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 4. Focusing on the z/OS Security Server (RACF) . . . . . . . . . . . . . . . . . . . . . . 414.1 What is RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.1 The RACF infrastructure for identification, authentication, and authorization . . . . 424.1.2 Sharing or synchronization of the RACF data base . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 RACF security functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.1 Identification and authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.2 User identity mapping for digital certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.3 User identity mapping for Kerberos tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.4 Resource access control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.5 X.509 digital certificate management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.6 RACF as a Kerberos user registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.7 Remote security services via the z/OS LDAP server . . . . . . . . . . . . . . . . . . . . . . 494.2.8 Support of the J2EE security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 RACF auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.1 The RACF auditing infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.2 RACF auditing controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.3.3 Exploitation of RACF auditing SMF records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4 Accessing RACF from Java applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.4.1 Java API for RACF services in the IBM JDK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.4.2 Java APIs in z/OS for RACF services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.5 Accessing RACF using the LDAP protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.5.1 Administering the RACF users and groups through LDAP . . . . . . . . . . . . . . . . . . 604.5.2 LDAP Change Log for changes in RACF USER and GROUP profiles and

users-to-groups connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.5.3 RACF Password Enveloping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.5.4 RACF remote services at z/OS V1R8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.6 Complementing z/OS RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.6.1 IBM Tivoli zSecure administration products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.6.2 IBM Tivoli zSecure CICS Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.6.3 Risk and compliance products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Chapter 5. A brief reminder about System z integrated hardware cryptography . . . . 795.1 Cryptographic function support in System z10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.2 Overview of the cryptographic devices in System z9 and z10 . . . . . . . . . . . . . . . . . . . 80

5.2.1 CP Assist for Cryptographic Functions (CPACF) . . . . . . . . . . . . . . . . . . . . . . . . . 805.2.2 The Crypto Express 2 Coprocessor (CEX2C). . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.2.3 Crypto Express 2 Accelerator (CEX2A) mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.3 Reminder on hardware coprocessors and logical partitioning. . . . . . . . . . . . . . . . . . . . 835.4 Reminder about z/OS hardware cryptography infrastructure . . . . . . . . . . . . . . . . . . . . 83

5.4.1 Reminder about ICSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.4.2 ICSF releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.5 Hardware cryptography exploitation on z/VSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.5.1 RSA acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.5.2 CPACF exploitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.5.3 Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

iv Designing for Solution-Based Security on z/OS

5.6 Hardware cryptography exploitation in Linux for System z . . . . . . . . . . . . . . . . . . . . . . 875.7 Setting up the hardware cryptography configuration of z/VM . . . . . . . . . . . . . . . . . . . . 88

Chapter 6. Using the LDAP directory as a User Registry . . . . . . . . . . . . . . . . . . . . . . . 916.1 Review of LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.1.1 The LDAP data organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.1.2 Access control in LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.1.3 Using the LDAP directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.2 Using the z/OS LDAP directory as a user registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.2.1 Supported SASL mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.2.2 TDBM- or LDBM-based user registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.2.3 Using the z/OS SDBM backend for authentication . . . . . . . . . . . . . . . . . . . . . . . 1006.2.4 z/OS LDAP auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.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 . . . . . . . . . . . . . . . . . . . . . . . 1047.1.1 User identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.1.2 Interoperable identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.1.3 Identity mapping in z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7.2 Trusted Third Party authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077.2.1 The conceptual view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.3 The concept of asserted identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097.4 z/OS and Trusted Third Parties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

7.4.1 Extending the z/OS Trust Domain with TTP authentication technologies. . . . . . 1107.4.2 z/OS as a Trusted Third Party. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Chapter 8. Overview of TCP/IP network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238.1 General discussion - non-secure network threats. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.2 Network protection and network security zone considerations . . . . . . . . . . . . . . . . . . 125

8.2.1 Common network models - overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268.2.2 Mapping network zones to an organization’s network components . . . . . . . . . . 1288.2.3 Practical design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

8.3 TCP/IP stack hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308.4 z/OS network protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

8.4.1 TCP/IP-oriented additional RACF protections. . . . . . . . . . . . . . . . . . . . . . . . . . . 1338.5 IP Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358.6 IPSec virtual private networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

8.6.1 IPSec protocols and modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1378.6.2 IPSec Security Association and key exchange. . . . . . . . . . . . . . . . . . . . . . . . . . 1388.6.3 Implementing network communication security with IPSec - IPSec modes . . . . 1408.6.4 z/OS IPSec characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.7 Application Transparent TLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448.7.1 AT-TLS implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1458.7.2 The AT-TLS policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1468.7.3 z/OS AT-TLS aware applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478.7.4 z/OS TN3270 server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

8.8 z/OS IPSec or AT-TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1488.9 Intrusion detection and z/OS Intrusion Detection Services . . . . . . . . . . . . . . . . . . . . 149

8.9.1 Intrusion detection overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498.9.2 Network-based intrusion detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1508.9.3 Host-based intrusion detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1508.9.4 z/OS Intrusion Detection Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Contents v

8.10 z/OS IP Security or IDS data collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528.10.1 z/OS Syslogd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528.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 basics155

9.1 Security environments and WebSphere Application Server for z/OS . . . . . . . . . . . . . 1569.1.1 WebSphere Application Server and z/OS - overview . . . . . . . . . . . . . . . . . . . . . 1569.1.2 WebSphere Application Server for z/OS communication flows . . . . . . . . . . . . . 1579.1.3 WebSphere Application Server-specific RACF protected resources . . . . . . . . . 159

9.2 WebSphere Application Server user identification and authentication . . . . . . . . . . . . 1609.2.1 WebSphere Application Server authentication mechanisms . . . . . . . . . . . . . . . 1609.2.2 WebSphere Application Server user registries . . . . . . . . . . . . . . . . . . . . . . . . . . 1639.2.3 Other WebSphere Application Server identity considerations . . . . . . . . . . . . . . 1639.2.4 WebSphere Application Server and asserted identity. . . . . . . . . . . . . . . . . . . . . 1659.2.5 Synchronize to OS thread. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

9.3 WebSphere Application Server authorization mechanisms . . . . . . . . . . . . . . . . . . . . 1679.3.1 Declarative security and programmatic security . . . . . . . . . . . . . . . . . . . . . . . . . 1689.3.2 Using SAF for authentication and authorization - summary . . . . . . . . . . . . . . . . 1699.3.3 Using Java Authorization Contract for Containers (JACC) for authorization. . . . 170

9.4 Using LDAP as a user registry for WebSphere Application Server. . . . . . . . . . . . . . . 1729.4.1 Using z/OS LDAP as a user registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1749.4.2 Using LDAP authentication and RACF authorization . . . . . . . . . . . . . . . . . . . . . 1749.4.3 Using z/OS LDAP as an authorization database . . . . . . . . . . . . . . . . . . . . . . . . 175

9.5 Web Services security overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1759.5.1 High level architecture for Web Services Security . . . . . . . . . . . . . . . . . . . . . . . 1769.5.2 Web Services Security for SOAP Message V1.0 feature overview . . . . . . . . . . 1809.5.3 Using identity assertion with Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1829.5.4 Web Services Security implementation in z/OS overview. . . . . . . . . . . . . . . . . . 1839.5.5 Security threats specific to XML SOAP messaging . . . . . . . . . . . . . . . . . . . . . . 186

9.6 WebSphere Application Server and auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879.6.1 Auditing capabilities for WebSphere Application Server for z/OS. . . . . . . . . . . . 1879.6.2 Security auditing service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1899.6.3 Remote Authorization requests performed via IBMRRAP . . . . . . . . . . . . . . . . . 189

Chapter 10. Tivoli products that team with the mainframe . . . . . . . . . . . . . . . . . . . . . 19110.1 The IBM Tivoli security portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

10.1.1 Tivoli security products that can execute on z/OS . . . . . . . . . . . . . . . . . . . . . . 19310.2 Tivoli security products used in our sample configuration. . . . . . . . . . . . . . . . . . . . . 193

10.2.1 IBM Tivoli Access Manager (TAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19410.2.2 IBM Tivoli Directory Integrator (ITDI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20410.2.3 IBM Tivoli Identity Manager (ITIM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Chapter 11. Sample configuration - identity provisioning, authentication and authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

11.1 Our sample configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22011.1.1 User populations and user registries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

11.2 Dealing with multiple directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22311.2.1 User provisioning and registry synchronization. . . . . . . . . . . . . . . . . . . . . . . . . 22311.2.2 User registries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22511.2.3 User registries - synchronization flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

11.3 Variations on identification and authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22811.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234How to get Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Help 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®CICS®DataPower®DB2®DFSMS™DFSORT™Domino®DRDA®i5/OS®IBM®IMS™Language Environment®Lotus Notes®Lotus®

MVS™NetView®Notes®OS/390®Parallel Sysplex®PR/SM™RACF®RDN™Redbooks®Redbooks (logo) ®RMF™S/370™System z10™System z9®

System z®System/370™Tivoli®VTAM®WebSphere®z/Architecture®z/OS®z/VM®z/VSE™z10™z9®zSeries®

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

http://www.ibm.com/legal/copytrade.shtml

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 CostaITSO Poughkeepsie Center

Axel Buecker, ITSO Tivoli Security Project ManagerITSO Austin Center

Arthur Fitzpatrick, Security Design and DevelopmentIBM Poughkeepsie

Richard Guski, STSM zSeries® Software Security ArchitectureIBM Poughkeepsie

Bruce Wells, RACF Development Software DesignerIBM Poughkeepsie

Deborah Mapes, RACF Design Software DesignerIBM Poughkeepsie

Timothy Hahn, Tivoli Chief Architect, Secure Systems and NetworksIBM Durham

Johan Varno, IBM Tivoli Directory Integrator Lead ArchitectIBM Norway

William J. O’Donnell, IBM Software Group, WebSphere Security Architect - Security DevelopmentIBM Madison

Hyen-Vui (Henry) Chung, IBM Software Group, Web Service Security DevelopmentIBM 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

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html

ibm.com/redbooks

� Send your comments in an e-mail to:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400

xiv Designing for Solution-Based Security on z/OS



http://www.redbooks.ibm.com/contacts.html

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.

1

© 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.

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

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.


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.


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 authenticationThis 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.

Access controlAccess 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.”

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.


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.

Data confidentialityData 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 integrityData 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.

AuditingAuditing 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.

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.

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.

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.


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


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


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 informationIt 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


� Sharing of security policy and service repositories� A mix of the above mechanisms

Information mappingInformation 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 federationInformation 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 deviceIn 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 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.


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.

2


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 instructionsPrivileged 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 mechanismWith 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.


Storage protectionFour 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 implementationOver 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 authenticationEach 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 operationsAccess to configuration information, environment activation, and resource allocation is controlled.

Audit and accountabilityAll 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 resourcesAccess 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 separationVirtualized 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 reuseObjects, 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 serviceThe 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.


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.

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:

Note: Pointers to the formal security evaluations of IBM products can be found at:

http://www.ibm.com/security/standards/st_evaluations.shtml.

Common Criteria

EAL1: Functionally Tested

EAL2: Structurally Tested

EAL3: Methodically Tested andChecked

EAL4: Methodically Designed,tested and reviewed

EAL5: Semiformally Designedand Tested

EAL6: Semiformally Verified Design and Tested

EAL7: Formally Verified Designand Tested

US TCSEC European ITSEC

D: Minimal Protection E0

C1: Discretionary Security E1

C2: Controlled Access E2

B1: Labeled Security E3

B2: Structured Protection E4

B3: Structured Domains E5

A1: Verified Design E6


� 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 IntegrityAs 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


Program Facility (APF) authorized. In the event that an IBM System Integrity problem is reported, IBM will always take action to resolve it.”

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.

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.

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.

z/VM CP

System z hardware

z/OSLinux

LogicalPartition

PCI Crypto

HiperSockets

OSAExpress IFL

Logical Partition

Guest LAN IUCV

VCTC

Logical Partition

PR/SM Microcode virtualizationLogical resourcesHiperSockets networks

z/VM Control Program (CP)Virtualization

Virtual devicesVirtual networks

FICONChannel

Linux Guest VM

Linux

virtualdevices

Linux Guest VM

Linux

virtualdevices

Linux Guest VM

Linux

virtualdevices

Logical andphysicalresources

Logical andphysicalresources

Logical and physical resources

VSWITCH


z/VM securityThe 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.

Figure 2-3 z/VM and RACF

z/VM and RACFRACF 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

Guest virtual machine owner(or AUTOLOG)

z/VM CP

Linux Guest VM

Linux

virtualdevices

Guest VMDirectory

X

RACF Admin

Linux user

CP Access Controls

LinuxData

Minidisk

Linux access control

RACF DBRACFGuest VM

SMFGuest VM SMF

RACF serviceowner ISPF

line commands


– 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 IntegrityA 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 supportz/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.


Figure 2-4 Hardware cryptographic coprocessor assignment to VM guest machines

LDAP support at z/VM V5.3z/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 securityz/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).

CPDedicatedqueue

Sharedqueue

z/OS guest

ICSF

Linux guest

z90crypt

Linux guest

z90crypt

Crypto engines

Guest DirectoryCRYPTO APVIRT

Image profileUsage domain 1,2+ APs 2,5,6 in online/candidatelists

CP

Crypto engines

libica

Domain1

libica

coprocessors 5 and 6

Guest DirectoryCRYPTO DOMAIN 1APDED 5 6

16 domain queues


LPAR

Domain 2Domain 2

Domain2

Coprocessor 2


Figure 2-5 z/VSE Basic Security Manager implementation

z/VSE hardware cryptography supportz/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 securityDuring 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.

Resource Managers(CICS, Connector Server, ..) VSE Control Fle BSM Control Fle

SAF Router

Security Manager(ESM) Security Server

RACFROUTE


Linux for System z hardware cryptography supportWhen 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 certificationsIBM 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



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.

3


� 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.

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.

ICSFOCSF/OCEP

Enterprise Identity Mapping (EIM)

System SSLNetwork Authentication

Service (Kerberos)z/OS Security Server (RACF)

IP FilteringIPSec VPNs

Intrusion Detection Services

AT-TLSELF/DCAS

z/OSLDAP

DirectoryServer

and client

z/OSPKI

Services

Networklevel

Security

MiddlewareSecurity

TransactionLevel

SecurityPlatform

levelSecurityz/OS

JAVAJ2EEWSS

OpenSSH….

RACF

FTP, TN3270, HTTP ServerWAS for z/OSCICS/TSWebSphere MQ...

A P I s

network

DCE Security Server


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 FacilityThe 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

ICSFOCSF/OCEP

Enterprise Identity Mapping (EIM)

System SSLNetwork Authentication Service (Kerberos)

z/OS Security Server (RACF)

IP FilteringIPSec VPNs


AT-TLSELF/DCAS

z/OSLDAP

DirectoryServer

and client

z/OSPKI

Services

Networklevel

Security

MiddlewareSecurity

TransactionLevel

Security

Platformlevel

Security

JAVAJ2EEWSS

OpenSSH….

RACF

FTP, TN3270, HTTP ServerWAS for z/OSCICS/TSWebSphere MQ...

X.509PKCS#10PKCS# 7PKCS#12RSA DSA

XML

X.509PKCS#10PKCS# 7PKCS#12

OCSPRSA DSA

SCEP

LDAPCRAM-MD5

DiGEST-MD5J2EEXML

SOAPWSSSAMLJAVA

…

OpenSSHKerberosSSL TLSSPKM-3LIPKEY

TCP/IP servicesIP V4/V6

IPSecIKE

DES T-DESAES SHARSA EMVPKCS11

DCE Security Server

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

Open Cryptographic Service Facility OCSFThe 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 SSLSystem 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 Servicesz/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 Serverz/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.

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


3.2.2 z/OS Integrated Security Services

LDAP Directory ServerThe 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

Network Authentication ServiceNetwork 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)

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.


� 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.

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 Centerz/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 ServicesA 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

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.


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.

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 serverThis 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/OSThis 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 clientThe z/OS LDAP client has been replaced by the IBM TDS client for z/OS at z/OS V1R8.

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.


Figure 3-3 The z/OS LDAP server and client evolution

The z/OS LDAP infrastructureFigure 3-4 is a global overview of the z/OS LDAP infrastructure as implemented with the ISS LDAP server and the IBM TDS.

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.

OS/390 V2R5

z/OSV1R6

z/OS V1R8TDBM coex

APAR OA15948

March 2007

Directory Server For z/OS

ISS LDAP Server

z/OSV1R8

OS/390 V2R4

Additional APIs

z/OSV1R4

EnablementAPAR OA19286

For z/OS V1.8 only

Stabilized ISS LDAP Server

Last functionalupgrade

FMID HRSL380

ISS LDAP Client Directory Client For z/OS

LDAP clientLDAP clientz/OS UNIX

Directory

RACFData base

ACL

Basic authSSL/TLS Kerberos

CRAM-MD5Digest-MD5

z/OS

Schema

IODF

TCP/IPTCP/IPstackstack

LDAP clientLDAP client

LDAP V3LDAP V3

OMVS shellTSO

ldapsearchldapmodifyldapdeleteldapmodrdn

backends

HCD

SDBM

DB2

RMF

LDBM

GDBM

Directory ACL Schema

HFSzFS

IODF Schema

RACF Schema

RMFschemaRMF

TDBMISS LDAP

Only

ITDS only EXOP

config

Applications


� 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.

� 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”).

� 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.

� 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.

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.

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.

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).

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 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 SysplexThe 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.

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 replicationThe 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.

z/OS UNIX

TCPIPstack

LDAPV3


DB2

Directory ACL SchemaHFSzFS

SysplexDistributor

Sysplex memberLDBM

TDBM

RACF

Sysplex data sharing

LDAPclient

z/OS UNIX

TCPIPstack

LDAPV3

Sysplex memberLDBM

TDBM

RACF

WLMRACF


Figure 3-6 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

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.

OptionalSSL/TLS

z/OS UNIX

LDAP clientTCP/IPstack

LDAP V3

z/OS UNIX

LDAP clientTCP/IPstack LDAP V3

DB2


HFSzFS

LDBM

TDBM

z/OS

z/OS


DB2


HFSzFS

LDBM

TDBM



� 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 ServerWe 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.


3.2.6 Communications Server Security Level 3 optional featureThe 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.


� 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.

APF and z/OS UNIX System ServicesThe 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.

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.


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 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.

4


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.


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.

Administrator

User

z/OS

Code requeststo access a resource

ApplicationAddress Space

SAF

z/OS ResourceManager

requestTo accessResource

X

RACFDatabase

userIDgroup…

Auditing

SystemManagementFacility

UserIdentificationAndAuthenticationor identitymapping

User Profiles

Resource AccessLists

RACF

Resource

Auditor

1

2

3 4

56

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) interfaceSAF 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.


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 passwordThe 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 phraseRACF 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 PassTicketPassTickets 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.


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.


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.


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.

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.

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.

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.


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.


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.

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.

Servletor EJB

Web / EJB Container

RMI/IIOP

Authentication/Mapping

USER profile ejbrole profile access list APPLDATA=role_surrogate

is principal in role ?declarativeor programmatic

http/https

SAF

Request

RunAs executionprincipal

otherbeans

Authorization to Role

RACF userID becomes the Java PrincipalCan also be LDAP or CUR

Can also be XML, CUR or TAM

3

1

2


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/OSThe 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 RACFIn 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.

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.


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.


� 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 loggingOwners 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 logThe 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-levelThe 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.


� 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 loggingAuditors 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 optionsUsers 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 optionsUsers 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.


� 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 accessAuditing 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 PacketThe 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 auditingSeven 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.


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 UtilityThe 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


� 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

Figure 4-3 RACF SMF Data Unload Utility

For more details, refer to z/OS Security Server RACF Auditor’s Guide, SA22-7684-08

SMF Dataset

DB2 Extender

b2b app

SMF Unload

ACCESS SUCCESS 20:06:10 1998-08-26 IM13 NO NO NO IBMUSER SYS1...


ACCESS INSAUTH 20:06:10 1998-08-26 IM13 YES NO NO IBMUSER SYS1...






Tabular Representation XML tagged document...<event>

<type>JOBINIT</type><result>FAILURE</result>...

/<event>...

DB2Database

customerapplicationsvendor

applicationsIBM

applications

HTML

browsers

customformat

customformat

5E29004A 4C060101 055FC9D4 F1F34040 40400003 00050000 00000044 0018000100000000 00000000 00000000 00000000 00000000 00000000 0000005C 00280002C8C2C2F7 F7F0F340 E5D3C640 40404040 40404040 40404040 C9D9D9C1 C3C5C54300001000 00000002 00000030 0000002A 0000000F 00000000 00000000 00000D84C9D9D9E4 D4C1D740 00001000 00000000 00000000 00000000 00000000 0000000500000000 00000000 C9D9D9C7 D4C1D740 00001000 00000000 00000000 0000000600000000 00000000 00000000 00000000 C9D9D9C7 E3E24040 00001000 0000000700000000 00000000 00000000 00000000 00000000 00000000 C3D3C1E2 E2F4404800000100 00000000 00000000 00000000 00000000 00000000 00000000 00000009C3E2E5D3 D3C14040 00001000 00000000 00000000 00000000 00000000 0000000000000000 00000000 ....

Raw SMF Record


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 generationJava 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:


� /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.

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.

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.

Javaapplication JSec

APIJVM JNDI TCP/IP z/OS

LDAPServer

SDBMbackend

RACF

UsersGroupsconnections

Provided in z/OS HFS:/usr/include/java_classes/userregistry.jar/usr/include/java_classes/RACFuserregistry.jar

Local or remote to z/OS

TCP/IP


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.

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

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

LDAP commands

TSO RACF commands

ldapadd ADDUSERADDGRPCONNECT

ldapmodify ALTUSERALTGRP

ldapdelete DELUSERDELGRPREMOVE

ldapsearch SEARCHLISTUSERLISTGRP

LDAP clientLDAP clientRACFData base

z/OS


LDAP LDAP ServerServer

SDBM RACF Schema

config

SSL/TLS

z/OS UNIX


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.

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.

SuffixDN(cn=RACFA,o=IBM,c=US)

objectclass=racfBase

Profiletype=Connectobjectclass=racfprofiletype

Profiletype=Userobjectclass=racfprofiletype

Profiletype=Groupobjectclass=racfprofiletype

racfid=GRP222,,profileType=User,…

objectclass=racfGroupand so on

racfid=XYZ111,profileType=User,…objectclass=racfUser

and so on

…racfuserid=XYZ111+racfgroupid=GRP222,,

profileType=Connect,…objectclass=racfConnect

and so on

… …


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 notificationRACF 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

LDAP clientLDAP clientRACFData base

z/OS


LDAP LDAP ServerServer

SDBM RACF Schema

config

SSL/TLS

z/OS UNIX

Directory ACL SchemaDB2

HFSzFS

GDBM

CHANGENUMBER=1202,CN=CHANGELOGobjectclass=CHANGELOGENTRYobjectclass=IBM-CHANGELOGchangenumber=1202targetdn=cn=ken34,o=Your Companychangetime=20031002003951.302193Zchangetype=ADDchanges=objectclass: inetorgpersoncn: ken34userpassword: *ComeAndGetIt*sn: Morgantelephonenumber: 123-456-7890ibm-entryuuid: 59290000-73D7-1F7B-94ED-40206404095

ibm-changeinitiatorsname=cn=dept68mgr,o=your company

Contents of theGDBM change log

as seen by theLDAP clientt

ACL


� NOTIFY.LDAP.GROUP


– Groups added using the ADDGROUP command– Group modifications made using ALTGROUP command– Groups deleted using the DELGROUP command

� NOTIFY.LDAP.CONNECT


– 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.

Figure 4-8 RACF Password Enveloping

dn: changenumber=13,cn=changelogobjectclass: topobjectclass: changeLogEntryobjectclass: ibm-changelogchangenumber: 13targetdn: racfid=JOEUSER,profiletype=user,o=ibm,c=uschangetype: modifychangetime: 20030729123000 Changes: replace: racfPasswordracfPassword:*ComeAndGetIt*ibm-changeinitiatorsname: racfid=JOEADMIN,profiletype=user,o=ibm,c=us

RACF LDAP eventnotification

Change log entryIn the GDBM backend

LDAP clientSearch fornew log entries

Get theracfPasswordEnvelope

objectSDBM backendRACF

DB

ldapsearch

ldapsearch

ldapmodify to targetdirectories

Selected user changes password

Password envelope Prepare passwordfor propagation

to target directories


The RACF Password Enveloping LDAP clientNote 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 EnvelopingFor 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.


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=<RACF userID>,cn=ictx

Figure 4-9 RACF remote services infrastructure

Remote authorizationThis 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

LDAP clientLDAP client

z/OS UNIX

z/OS

TCP/IPTCP/IPstackstack LDAP V3LDAP V3

backends

SDBM

LDBM

GDBM

TDBM

EXOP

ds.conf

ICTX

# ICTX extended operations support sectionDatabase ictx ITYBIC31 suffix « cn=ictx »

Remote auditingRemote authorization

Identity Cache


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.

Figure 4-10 Remote authorization

Remote auditingThis 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.

Remoteuser

Remoteapplication

IBM TDSFor z/OS

ICTXbackend

RACF DB

APPLSRVR

REMOTUSR

Remote resource

SAFRACROUTE

LDAP

IRR.LDAP.REMOTE.AUTH

LDAP authenticated bindwith DN: racfid=APPLSRVR,cn=ictx

SMF auditingOf accesses

?


Figure 4-11 Remote auditing

RACF identity cacheThe 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.

Remoteapplication

IBM TDSFor z/OS

ICTXbackend

RACF DB

APPLSRVR

LDAPSRVR

R_auditxCallable service

LDAP

IRR.LDAP.REMOTE.AUDIT

LDAP authenticated bindwith DN: racfid=APPLSRVR,cn=ictx

SMF type 83Subtype 4

IRR.RAUDITX


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.

z/OS

DistributedApplication

z/OS server application

ACEEACEE

User Identified and authenticatedin a distributed security context

1Identification information

2

Identity Context

Reference (ICR)

3

Extended ACEEto Auditing

Regular ACEE

+Distributed identity

+ Registry name

+ Host name

+ Authenticationmechanism

45

ICR passed as basic authentication

to z/OS application

End-To-End user accountability

RACROUTE REQUEST=VERIFY,ENVIR=CREATE

Optional identityMapping (EIM or other)

Java

AP

I

Distributed identity domain SAF identity domain

Java API orR_cacheserv

LDAPEXOP

Identity Cache


– 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.


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.


Figure 4-13 IBM Tivoli zSecure Admin

IBM Tivoli zSecure VisualThis 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.


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.


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 ManagerThe 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.


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).

z/OS

SAF

ResourceManager

zSecure•Admin•Visual•CICS tools•Audit•Alert•Command Verifier

Insight

TSOM

Tivoli zSecure Suite

Insight

Tivoli Security Operations

Manager(TSOM

Tivoli Compliance Insight

Manager(TCIM)

TCIM

zAlert is a real time mechanismthat monitors events on zOSand matches the events against a pre-set security policyOther alerts

From otherdevices/platforms

Data collected and normalizedinto 7 w’s•Who•What•On what•When where•Where from•To where

Provides the compliance dashboard

From otherdevices/platforms

applications RACF


Figure 4-17 BM Tivoli Security Operations Manager display

Tivoli Compliance Insight ManagerTivoli 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


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 AuditThe 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


� 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 AlertThe 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


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 VerifierThis 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


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).

5


5.1 Cryptographic function support in System z10System 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


http://csrc.nist.gov/cryptval/140-2.htm

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) modeCEX2A 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.

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).

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.


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 <AP number>.<domain number>.

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.

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.

Important: The combination <AP number>.<domain number> must be unique in the whole set of active logical partitions in the system at any time, meaning that no more than one active logical partition can get access to a specific <AP number>.<domain> combination.

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.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.

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

Hardware

z/OS

ICSF

System SSL

Middlewares/Applications

IBM SDK

CEX2Cdomain

Master Key

CPACF

httpLDAP TN3270 FTP

CICS TS…

RACFVTAMVPNKerberos

PKI Services

PKCS11…

IMSDB2z/OS Encryption FacilityRSA Bsafe

Applications that use theCDSA API

Key datasets Secure keysClear keysPKCS11 tokens

RACFTSO/E

Optional TKE Workstation

CKDSPKDSTKDS

CPACFdirect call fromapplications

OCSF

WebSphereJAVA

PKCS 11

Applications that use The PKCS#11 API


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.

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.

� 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.

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.

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.


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.

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.

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.


http://www.ibm.com/eserver/zseries/zos/downloads

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.

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.

TCP/IP

SSLD

SSLForVSE

SSLFor VSE

API

CryptoVSE

Non SSL-enabledapplication

SSL-enabledapplication

Applicationwith

cryptography

CEX2Cdomain

CPACF

TCP/IP

Clear RSA key only

VSE CryptoDevice driver


� 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.

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

z90crypt (device)

libica

PKCS#11

Crypto Express2 Coprocessordomain

CPACF

Application

API

API

APIAPI

JavaApplication Middleware/

Application(e.g.

OpenSSlengine)

IBMPKCS11Impl


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.

Figure 5-4 Hardware cryptographic coprocessor assignment to VM guest machines

CPDedicatedqueue

Sharedqueue

z/OS guest

ICSF

Linux guest

z90crypt

Linux guest

z90crypt

Crypto engines


Image profileUsage domain 1,2+ APs 2,5,6 in online/candidatelists

CP

Crypto engines

libica

Domain1

libica

coprocessors 5 and 6

Guest DirectoryCRYPTO DOMAIN 1APDED 5 6

16 domain queues


LPAR

Domain 2Domain 2

Domain2

Coprocessor 2


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.

6


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 filesThe 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.


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 typesAny 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 entryAn 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.

Figure 6-1 Example of LDAP DIT

oc=countryc=us

oc=organizationo=IBM

oc=personcn=John DoeuserPassword=xxxxx

oc=countryc=fr

oc=organizationo=ACME

dn: "c=us"

dn: "o=IBM,c=us"

dn: "cn=John Doe,o=IBM,c=us"

dn: "c=fr"

dn: "o=ACME,c=us"

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 nameNote 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 entriesSome 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 DITsUsually 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 filesLDAP 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.


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 authenticationThe LDAP user authentication occurs during the bind operation and can be achieved using the following different mechanisms.

Simple bindAll 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.

Figure 6-2 LDAP authenticated bind

oc=countryc=us


oc=personcn=John DoeuserPassword=xxxxx


dn: "c=us"

dn: "o=IBM,c=us"

dn: "cn=John Doe,o=IBM,c=us"

LDAPServer

LDAP client

« binddn: cn=John Doe, o=IBM,c=us

Password=xxxxx»

VerifyUserpassword

Authenticated DNscn=John Doe,o=IBM,c=us….Groups list….

Successfulauthentication

If needed forAccess control


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 processWhen 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 entryAs 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.


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 registryOnce 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 membershipUser 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.


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 encryptionThe 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 AuthenticationThe 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


(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.

Figure 6-3 z/OS TDBM or LDBM Native Authentication

z/OS LDAP user group objectsThe 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

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.

oc=countryc=us


oc=personcn=Johhn DoeIbm-nativeid=JDOE


Rootdn: "c=us"

dn: "o=IBM,c=us"

dn: "cn=john Doe,o=IBM,c=us"

LDAPServer

VerifyUserID + password

LDAPClient

TDBM or LDBM

Successfulauthentication

z/OS

password

userID

« binddn: cn=John Doe, o=IBM,c=us

Password=xxxxx»

RACFuserIDs/passwords


� 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.

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 dataThe 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 dataWhen 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:

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.


� 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 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.

7


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 identitiesThe 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.


Authorization and identity mappingOperating 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 auditingIt 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 mappingRACF 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 mappingTwo 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.

Kerberos principal name mappingOnce 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

/.../<Kerberos_realm>/<Kerberos_principal name>/

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 /.../<kerberos_realm>/, in which case all Kerberos principal names in this realm will be mapped to the RACF user ID specified in the APPLDATA field.

Accountability of the original identityThe 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.

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.


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:


– 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.


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

TrustedThirdParty

1-provideidentity-proceed with

authentication and request credential 2-get unforgeable

Identification and authentication credential

3-use credential

Server A Server B

APIs to•Validate credential with trust in TTP•Map to a local userID (1:1, many:1)•Control access against the local ID

•A highly trusted and scalable system•With a secure authentication scheme•Provides standardized identity credentials(e.g. X.509 certificates, Kerberos tickets)

Industry standards

APIs to•Validate credential with trust in TTP•Map to a local userID (1:1, many:1)•Control access against the local ID

Platform-specificimplementation

Platform-specificimplementation

delegation or identity assertation


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.


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 ServiceThe 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 protocolKerberos 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.

Platform Securityhardware and operating system

security

TCP/IPSecurity

Business Processes

TransactionSecurity

z/OS

The z/OS « Security island »•RACF identification/authentication

•userID•Password/password-phrase•Passticket

•RACF access control•Discretionary•MLS

•Tivoli zSecure

TRAFFICMONITORING

MESSAGEMODIFICATION

IMPERSONATION

INTRUSIONDENIALOFSERVICE

TrustedThirdParty

The z/OS Extended Trust Domain•RACF hosts the Trust Policy•RACF maps userID to

•Certificate’s subject•Kerberos principal

RACF

Trust Policyin

RACF


Kerberos principles of operationFigure 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).

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

Server A

Ticket GrantingServer

Kerberos Key Distribution Center

Log Me In

Authorize Meto Server B

ClientApplication

login

Service Ticketfor server B

Client

Kerberos KDC Security Realm

Server B Server C

Service Ticket to server B

I recognize you, hereis an Authentication

TicketAuthentication

ServerLoginto client

workstation


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 implementationThe 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.

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.

(AS)Authenticates UsersGrants TGTs

(TGS)Generates Session KeysGrants service tickets based on TGT

SKRBKDC

AuthenticationServer

Ticket GrantingServer

RACF profile classes ƒ REALMƒ KERBLINK

KERB segment in user profile

kerberos enabled application

SAF

ticket from client

R_kerbinfo

R_ticketserv

R_usermap

KerberosKey Distribution Center

(KDC)

Kerberos clients

z/OS

KerberosRegistry

RACF


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.

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 implementationHere 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

Windows XP

z/OSKerberos enabledservice

RACFKDC

z/OS - RACF KDC

Windows Active Directory

Windows XP

inter-realmkey

inter-realmkey

Kerberos enabledservice


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.


– 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.

z/OS PKI Servicesz/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.

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

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.

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.


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.

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.

VerifiesCA's

Signature

Certificates andCRLs

Repository

Certification Authority

Certificate,exploiting

Entity

CerificateOwning Entity

1-Certificate Request

2-Certificate Issuance

4-Certificate RevocationChecking

Certificate Revocation ListsIssuance

3-Certificate Utilization

The Public Key Infrastructure (PKI) as described in the IETF

PKIX standards

CA DigitalSignature

Mary'sPublic Key

"Mary"

Mary's Digital Certificate

The Certification Authority: the Trusted Third Party

Mary'sPrivate Key

Check ownership of Mary's private key

Authentication

Identification Digitalcertificates of

trustworthy CAs


� 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 Servicesz/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.

Figure 7-7 z/OS PKI Services

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.

•User requests and receives X.509 V3certificate via browser interface

•Client can get a certificate via SCEP (Simple Certificate EnrolmentProtocol)

•Certificate Revocation Listpublished in LDAP directoryand HTTP files •Support for OCSP (OnlineCertificate Status Protocol)

z/OS HTTP Server

SCEPclient OCSP

requestor

1

2

34

5

667

3


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.


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.

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.

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.

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.


– 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.

� 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.

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.


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

8


8.1 General discussion - non-secure network threatsMuch 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


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.

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 TranslationOne 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.

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.

Chapter 8. Overview of TCP/IP network security 125

Firewall technologiesFirewalls 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.


Figure 8-1 An approach to network security zones classification

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.

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.

Internet InternetDMZ

ProductionZone

Intrarnet

ManagementZone

Uncontrolled

Restricted

Controlled ControlledSecured

client


8.2.2 Mapping network zones to an organization’s network componentsThis 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.


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 networksThe 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.


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)


Production Zone

Uncontrolled Controlled Restricted

Loadbalancer

Non-criticalWeb server

Reverse proxyserver

App Server

App Server

App Serverclient


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.

– 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

Note: z/OS exploits RACF protection of the auditing data sets or files. It does not provide integrity checking of the auditing logs contents.


http://www.cert.org

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.

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).

•All protections are optional•Up to 8 TCP/IP stacks can runconcurrently in a single z/OS instance

IPSec VPNs provide for TCP/IP communications encryption andauthentication. All cryptographic operations are handled by the TCP/IP stack

IP filtering blocks out all IP traffic that this systems doesn't specifically permit, per

SourceDestinationProtocol, …

IP Filtering


IPSec

SAF protection

Intrusion detection services protect against attacks of various types on the system's legitimate (open) services

ScanningHostile packetsTraffic flood

RACF is used to preventunauthorized user access to TCP/IP resources (stack,

ports, networks) z/OS TCP/IP Stack

Networkadapter e.g. OSA-E

port

Application

e.g. WebSphere Application Server

ApplicationTransparent TLSAT-TLS provides SSL/TLS

protection Independently of the application

network


� 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.

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 accessThe 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 WORKSTNDEFAULT 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).

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.


Port accessSimilar 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

PORT21 TCP * SAF SERVER123 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.

Stack accessContinuing 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.

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.

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.


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.

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.


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).

Figure 8-5 IP Filtering for routed traffic

Network Interfaces

IP Networking Layer

Transport protocol layer TCP and UDP

Sockets

Applications

PERMIT

DENY

IP network

POLICY AGENTPOLICY AGENT

IP FilteringPolicy

Administrator

Network Interfaces

IP Networking Layer

Transport protocol layer TCP and UDP

Sockets

Applications

IP network

POLICY AGENTPOLICY AGENT

Administrator

DENY

PERMIT

IP FilteringPolicy


Default policyThe 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.

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.

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.


� 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.

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.

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.


Internet Key Exchange protocolThe 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.

� 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.

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.


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 modeIn 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 modeIn 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.

IP/ICMP

Data Link

TCP/UDP

Sockets API

IKED

IP/ICMP

Data Link

TCP/UDP

Sockets API

IKEDIKE key Establishment

z/OS TCP/IP stack

IKE Phase 1 : secure installation of IKE keytypically occurs once a day or once a week

Key server authentication via RSA signature or preshared key

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 Key IKE Key

VPN Data Key

VPN Data Key

certificate

Encrypted data

MAC-SHA and HMAC-MD5 authenticationDES and 3DES encryptionAES encryption

certificate

Any systemIPSec compliant

stack


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.

SRC@, DST@,...

PayloadSRC@, DST@,...

AHHdr

Payload


AHHdr

New IP Hdr

Authenticated

Authenticated

AH-Transport

AH-Tunnel

Original Datagram

Payload

New IP Hdr

Original Datagram

ESP-Tunnel

ESP-Transport

SRC@, DST@,...

ESPHdr

Payload

ESPTrailer

ESPAuth

ESPTrailer

ESPAuth

SRC@, DST@,...ESPHdr


Encrypted

Encrypted

Authenticated

Authenticated


Figure 8-8 IPSec and network segments protection

8.6.4 z/OS IPSec characteristics

Cryptographic algorithmsThe 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).

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.

Host-to-Host: End-to-End Security Association

Host-to-gateway: Protect segment of data path

Tunnel mode IPSec SA

G1 G2intranet

Connection

H2

H1 H2

ConnectionTransport mode IPSec SA

Data endpoint

Security endpoint

Legend

Gateway-to-Gateway: Protection over Untrusted Network Segment

G1 G2Internet/intranetH1

Connection Tunnel mode IPSec SA

H1 intranet

intranet intranet H2

Internet/intranet

Internet/intranet


The NAT Traversal RFCs 3947 and 3948 are supported by the z/OS TCP/IP stack.

zIIP Assisted IPSecBeginning 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.

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 infrastructureBeginning 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.

ApplicationApplication

TCP/IP TCP/IP

zIIP

IPSec processing

No IPSec IPSec with no zIIP IPSec with zIIP

TCP/IP(SRB Mode)

Candidate for zIIPAssist

ApplicationIPSec processing

IPSec processing

General Purpose CP General Purpose CP General Purpose CP


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.

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.

...

.. Stack Eight

z/OS image 1

iked.conf

iked.conf

secure TCPconnections

CentralizedRACF

certificate administration

nss.conf

Certificates and private keys for images 1 to n

IKE peer

z/OS image n

z/OS image x Centralizedmonitoring

IKE Daemon

Network Security Services

Stack One

Stack One

Stack Eight

RACFKeyring

IKE Daemon


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.


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.

Network Interfaces

IP Networking Layer

TCP

Sockets

RACF certificate services

AT-TLS awareand controlling

applications

System SSL calls

Optional APIs for TLS-aware applications to control start/stop of TLS session Policy

Agent

ApplicationTransparent TLS

policy flat file

SSL/TLS communication with the partner application

Basic AT-TLSapplications

AT-TLS


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

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 serverThe 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.

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


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


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

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

IPSEC AT-TLS

Traffic protected with data authentication and encryption

All protocols TCP

End-to-end protection Yes Yes

Segment protection Yes No

Scope of protection Security association1) all traffic2) protocol3) single connection

TLS session1) single connection

How controlled IPSec policy1) z/OS responds to IKE peer2) z/OS initiates to IKE peer based on outbound packet, IPSec command, or policy autoactivation

AT-TLS policy1) For handshake role of server, responds to TLS client based on policy2) For handshake role of client, initializes TLS based on policy3) Advanced function applications

Requires application modifications No No, unless advanced function needed 1) Obtain client cert/user ID2) Start TLS

Type of security Device-to-device Application-to-application

Type of authentication Peer-to-peer 1) Server-to-client2) Client-to-server (opt)

Authentication credentials 1) Pre-shared keys2) X.509 certificate

X.509 certificate

Authentication principals Represents host Represents user

Session key generation/refresh Yes with IKENo with manual IPSec

TLS handshake


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.

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.

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.


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.

Figure 8-12 z/OS IDS setup

Install IDS Policy in

stack

TRMD

SOCKETS API

TRANSPORT LAYER TCP/UDP

IP NETWORKING LAYER

NETWORK INTERFACES

Intrusion Event

Log Events

Trace Suspicious

Activity

Event Messages to

Console

ATTACK

POLICY AGENT

IDSPOLICY

SYSLOGD

TRACES


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

The z/OS Syslog facility supports these priority codes:

0 Emergency1 Alert2 Critical situation3 Error4 Warning5 Notice6 Information7 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 messagesSyslogd 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)

Application Syslogd record identifications

Primary syslog facility

Other syslog facility

AT-TLS TTLS daemon auth

IKE IKED local4 none

TRMD TRMD daemon (used for IDS logging)

local4 (used for IP Security logging)


� 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.

Figure 8-13 Complementing z/OS network security


ProductionZone

Intranet

ManagementZone

Uncontrolled

Restricted

Controlled ControlledSecured

Client


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).


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.

9


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.

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

Application Server Node

J2EE scalable application server

Controllerregion

Servant

WebSphere Application Server runtimeenvironment

J2EEapplication

z/OS userid / UID MVS userid / UIDMVS userid / UIDz/OS userid / UID zOS Security and SAF

JVM

Java 2 Security

J2EE Security API

WebSphere Security

JavaPrincipal

ResourceConnector z/OS userid / UID

z/OS

TCP/IP 1

2Web Services Security

httpRMI/IIOP

JMS

3


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).

HTTPThe 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 communicationsThe 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.

CSIv2RMI/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 communicationsRMI/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 communicationsThe message service is not a specific TCP/IP protocol; it comprised of TCP datagrams.


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 classSERVER class is used to control access to the controller region by a servant region.

CBIND classCBIND 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 classThis 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.<authenticated User ID> resource in the SURROGAT class.

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”.


BBO.TRUSTEDAPPS in the FACILITY classWebSphere 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) frameworkThe 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)


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 subjectA 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 configurationDefault 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


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.

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.

Java client

Web client

Enterprise beansauthenticator

Webauthenticator

ORBCurrent object

CSIv2, TCP/IP, SSL/TLS

HTTP, SSL/TLS

Basic orToken credentials

Basic, token orcertificate

Loginmodule

SWAMmodule

LTPAmodule

credentials

credentials

Federatedrepositories

LocalOS

StandaloneLDAPregistry

Standalonecustom registry

Receivedcredentials

Receivedcredentials

WebSphere Application Server

Authenticationmodule

1

1

2

2

3

3

4

4

5

5


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 identityThe 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.


J2EE identityThe 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 identityThe thread identity is attached to a process thread executing within WebSphere Application Server. This identity can be one of the following types.

Java thread identityThe 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 mappingThe 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.


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 validationAn 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.

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

User

Proof ofServer Identity

User IdentitySession IdentSession Ident

1Trusted

Proxy Server


User Identity


User Identityrequest

forwardedrequest

Web Authenticator

App Server

•validate origin•return identity

TAI


User Identity


User Identity

User Identity

2

4

3


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.

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).


User Identity

TAM Security Server


forwardedrequest

Web Authenticator

• validate origin• return identity

TAI


2 4

3TAM Directory

TAMUSER

GROUP-1

GROUP-2

TAM Directory

TAMUSER

GROUP-1

GROUP-2

Credential

Build Credential1

Java Subject

Credential WebSphere ApplicationServer Credential

Credential

Java SubjectC

redential

Java SubjectC

redential


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.<authenticated User ID> in the SURROGAT class.

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.


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 securityDeclarative 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

Group

Role

User

Defined byApplication Deployer

Group

Role Principal Mapping

Resource Role Mapping

Defined byApplication Assembler

Web URL

EJB Method

Application Deployment Descriptor

UserUser UserUser

User

Role

Group User Mapping


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 securityThe 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.


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 <roleID> is a valid RACF user ID:

RDEFINE EJBROLE roleX UACC(NONE) APPLDATA(<roleID>)

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

Servletor EJB

Web / EJB Container

RMI/IIOP

Authentication/Mapping

USER profile ejbrole profile access list APPLDATA=role_surrogate

is principal in role ?declarativeor programmatic

http/https

SAF

Request

RunAs executionprincipal

otherbeans

Authorization to Role

RACF userID becomes the Java Principal

1

23

4


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.

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.

JACC Provider

Policy Configuration

Provider Repository

Access Decision

J2EE Container

Application Management(deploy, undeploy) Access Enforcement

Manage resources, roles, mappings Access Allowed?

Application Admin

User


WebSphere Application Server with the TAM JACC Provider architectureThe 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.

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.

TAM Auth Server(s)

WebSphere 6.x

TAM JACC Provider – shipped with WebSphere Application Server 6.x

AM Java Runtime – shipped with WebSphere Application Server 6.x

Replicated TAMPolicy Db

Policy Configuration Access Decision

Application Management(deploy, undeploy) Access Enforcement

TAM Auth Server(s)

TAM Policy Server

Master TAMPolicy Db

TAM Server

ApplicationAdmin User


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 filterThis 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 filterThis 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 mapThis 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 mapThis 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 mapThis 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 modeThis 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


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

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

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.


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.

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).

Important: IBMRRAP only provides for authorization for J2EE applications roles. It does not support obtaining authorization for the WebSphere Application Server administrative roles.


http://www-03.ibm.com/systems/z/os/zos/downloads/#asis

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.

Figure 9-9 Web Services high level architecture model

WSS Runtime

Request Generator

Response Consumer

WSS Runtime

Request Consumer

Response Generator

Client Server

Client Deployment Descriptor

Client Binding configuration

Server Deployment Descriptor

Server Binding configuration

Request Generator Configuration

Response Consumer Configuration

Request Generator Configuration

Response Consumer Configuration

Request Consumer Configuration

Response Generator Configuration

Request Consumer Configuration

Response Generator Configuration


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 consumerThis 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.

JAX-WS model overviewThe 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.

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.


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.

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:

JAX-WSService

Generator

Generator

Consumer

ConsumerRequest

Response

Requestor Provider

JAX-WSClient

(or usingWS API)

PluggableToken Framework

Policy Set Policy Set

PluggableToken Framework

invokes invokes

JAAS CallbackHandler

JAAS LoginModuleJAAS LoginModule

JAAS CallbackHandlerSecurityToken SecurityToken


� 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.

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.

Figure 9-11 Web Services transport and message authentication

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.

Web Application Server

Web Application Server

Servlet

EJB

SOAPRuntime

Servlet

EJB

SOAPRuntime

SOAP/HTTP

SOAP

J2EE Container

bob

wsse:UsernameToken<bob:password>

bob

authenticationbased on WS-Security

SOAP/HTTP

SOAP

J2EE Container

bob

wsse:UsernameToken<bob:password>

bob

authenticationbased on WS-Security

HTTP request

HTTP BasicAuth:<joe:password>

joe

joe

RMI/IIOP request

CSIv2 protocol:<alice:password>

alice

authentication by ORB based on CSIv2

authentication by HTTP end point based on HTTP

BasicAuth

http://www.fabrikam456.com/travelServices

http://www.fabrikam456.com/travelServices

joe

Alice


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).


Non-OASIS activities - specificationsIBM 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-FederationThis 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.

Figure 9-12 shows the relationship between these specifications.

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.


http://www.ibm.com/developerworks/library/specification/ws-secmap

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.

SOAP Foundation

WS-Security Foundation

Web Service Security

X.509 Token Profile Username Token Profile

SAML Token Profile SOAP With Attachments

Kerberos Token Profile

REL Token Profile

WS-Security Policy

WS-Secure Conversation WS-Federation

WS-Trust

WS-Authorization

Specifications not published yet

Specifications published

StandardsXML Digital Signature XML Encryption

WS-Privacy


Figure 9-13 depicts the identity assertion trust process.

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.

WSS Runtime

Request Generator

Response Consumer

WSS Runtime

Request Consumer

Response Generator

Server s1 Server s2

Secured SOAP message

Secured SOAP message

Identity (username token): bobTrust mode (username token): xxx/pwd

xxx/pwd xxx

bob

Downstream call

JAAS Login Configuration

Trusted ID Evaluator


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

PKDSCDKS

ICSF

JVMIBMJSSE2

IBMJCECCA

Hdw Crypto

RACFUser registryAccess control DB

keyrings

WebSphere Application Server Container

WebSphere Application Server – Web Services runtime

Java Crypto APIs

JAAS

WS-Security

z/OS

Java Support

HDW Crypto Support

User RegistryRolesCertificates keystore/truststore

z/OS Network Security

IBMCertPath

Configurations: JAAS, LTPA, SSL, providers, …


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.

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.

ICSF

CEX2C

Master KeyCPACF

•Digital Signatures via RSA •One-way: SHA1, SHA256, MD2, MD5•Symmetric Algorithms -- DES, 3DES, AES128•Asymmetric Algorithms – RSA•Random number generation

PKDS

JCE Provider(IBMJCECCA)

JVMRACF

keyrings

WebSphere Application ServerContainer

HFSfile

Java« keystores »

JSSE Provider(IBMJSSE2)

API API

Supported keystoresJCEKS (file based)•JCECCAKS (PKDS)•JCECCARACFKS (RACF with PKDS)•JCERACFKS (RACF/SAF)


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.


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.

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.

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.

IP FirewallServer

SOAP request

XML Firewall


� 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.

WebSphere Application Server authorization auditing with RACFThe 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.

Note: WebSphere Application Server does not exploit the syslog daemon facility.


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 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)

10


10.1 The IBM Tivoli security portfolio

The IBM Tivoli portfolio of security products is represented in Figure 10-1.

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.

IBM Tivoli

SecurityOperationsManager (TSOM)

IBM Tivoli Federated Identity Manager

IBM Tivoli Access ManagerTAM for Enterprise SSO

TAM for e-businessTAM for operating systems

TAM for Business Integration

IBM Tivoli Identity Manager (TIM)

IBM TivoliDirectory Server

IBM Tivoli Directory Integrator

IBM Tivoli

ComplianceInsight

Manager (TCIM)

IBM Tivoli

zSecure


� 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

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.

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.

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 productsThe 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)

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 conceptTivoli 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

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.


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.

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.

Bank App Managem

Appl A

servlet

Protected object spaceProtected object space

Policy TemplatesPolicy Templates

Corporate Web ACL

Employee Database ACL

Protected Object Policy

BankApplicationBankApplication / / servletservlet / / stockstock--valuevalue

User Peter ---------T-m-rx-Group Employee --------T----rx-uthenticatedunauthenticated ---------------

Time-of-day accessPrivacy, Audit

Stock value


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.

User registry andAccess Control Lists

at the Installationlevel

Front-endApplication

Protectedresource

Object / ACLDatabase

LDAPUser Registry

PolicyServer

Access Policy EnforcerSystem A

TCP with SSL

aznAPI

Access Policy EnforcerSystem C

Access PolicyEnforcerSystem B

IdentityObjectAction

Yes/NoAdditional

information

Administration


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 detailsThe following sections provide implementation-related details.

User registryThe 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.

TAM Policy Server and additional componentsThe 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.

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.


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 managersResource 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 proxyA 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


Figure 10-4 TAM and the IBM WebSeal authorization reverse proxy

JunctionsThe 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-onWebSEAL 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.

Installation objectsACL

LDAPUser Registry

TAM

WebApplications

Linux…

Other Policy Enforcers

WebSEAL

HTTPuser

Authenticatedand authorized


Can be LDAP onz/OS

System x


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.


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.

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

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.

MQ

PU

T

MQ

GE

T

MQ

OPEN

MQ

CO

NN

EC

T

QueueManager

OAMCode ExitsCode Exits

AuthorizationServices

ACLs

UsersAuthorization

Services

ACLs

Users

Crypto ServicesCrypto Services

Queues

MCA

MQSeries

CustomerApplication

PD/MQPD/MQ

Not used with TAMBI Not used with TAMBI


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/OSTAMBI 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.


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

RACF

z/OS

SAF

ResourceManager Installation

objectsACL

LDAPUser Registry

TAM

z/OS Policy DirectorAuthorization Services

Access authorizationand resource attributes

MQBI

MQApplications


Can be LDAP onz/OS


PDAS


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 operationsFigure 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.


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 systemsITDI can execute on the following operating systems:

� AIX� HP-UX� Linux

Assembly LineSQL

database

XMLDocument

JDBC Connector

FileSystem Connectorw/ XML Parser

LDAP directory

LDAP Connector

SQL database

XMLDocument

JDBC Connector

FileSystem Connectorw/ XML Parser

LDAP directory

LDAP Connector

Main-frame

Linux

ITDI

Directory

.net

WebServices

WebServices

Database

MQ

AIXMain-frame


� Sun Solaris� Windows� i5/OS� z/OS

Synchronizing data with ITDIWhen 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 securityIt 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 scenarioAlthough 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.


ITDI component structureITDI 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.

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.

ConnectorsConnectors 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.

Change log

EventHandlersEnable the system to respond to predefined events, thus enabling real-time integration

ConnectorsConnect to a device, system or application and perform actions on data appropriately Parsers

Interpret and transform incoming data into the desired format

EventSystems

LDIF FileRDBMS

Directory

Changedattributes

Target directory

AssemblyLinesExecute data flows based on the configuration of individual Connectors. EventHandlers, Parsers and the business logic driving process

Change log

EventHandlersEnable the system to respond to predefined events, thus enabling real-time integration

ConnectorsConnect to a device, system or application and perform actions on data appropriately Parsers

Interpret and transform incoming data into the desired format

EventSystems

LDIF FileRDBMS

Directory

Changedattributes

Target directory

AssemblyLinesExecute data flows based on the configuration of individual Connectors. EventHandlers, Parsers and the business logic driving process


ParsersUnstructured 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.

EventHandlersEventHandlers enable the system to respond to predefined events, thus enabling real-time integration.

HooksHooks enable developers to describe certain actions to be executed under specific circumstances or at any desired points in the execution of an AssemblyLine.

ScriptsThe 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 componentThe 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 exampleFigure 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.

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.


Figure 10-9 ITDI use case example

New user creation in the TAM user registry1. When an LDAP directory entry creation event is detected, ITDI starts AssemblyLine 1

(AL 1).

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 database1. 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.

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.

Note: The event detection can be performed through the GDBM back-end of the z/OS LDAP server.

Note: The event detection is done through the GDBM back-end of the z/OS LDAP server.

RACFADDUSER

UsersTDBM/LDBM

SDBM

AddTo

LDAP

Get NewUser

AddNativeAuth

Get NewUser

AddTo

RACF

AddNativeAuth

Installation objects

ACL

TAMLDAP user

registry

New RACF user

New TAM userTAM administratorRACF administrator

GDBM

ITDI – Assembly Line 1

ITDI – Assembly Line 2

z/OS LDAP


4. AL 2 creates the new user entry in the TAM user registry.

AuditingAlthough 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 ITIMTo implement the concepts involved in Identity Management, the ITIM functional architecture is based on the following entities that are to be managed.

UserIn 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.

AccountHere, 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.

AttributeThe term attribute refers to the additional meaningful information associated to the user that the exploiting organization wants to find in the account.

PasswordEvery 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


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.

Group membershipsA user’s membership in a group is granted by ITIM by specifying a group attribute in accounts.

Managed systems and applicationsITIM 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 entitiesIdentity Manager uses the following entities in its identity management processes.

Organizational tree and rolesThe 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

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.


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 rolesIdentity 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.

PolicyIdentity 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

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.


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.

WorkflowITIM 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 logsITIM 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

ReportsITIM provides several types of reports that can be used for administering and tracking activities.

ITIM key functions and logical architectureThe 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 architectureITIM is a Java application with a logical architecture as shown Figure 10-10.


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:

End Userbrowser

Administratorbrowser

Supervisorbrowser

Application

Web User Interface

Service

Java API

DatabaseLDAP

Entity puts/gets

Transactions info,schedule

reads/writes

OperatingSystem

Adapter

RDBMS

Adapter

Application

Adapter

Account provisioning/reconciliation

User/Administrator requests/responses


� HP-UX� IBM AIX� Red Hat Enterprise Linux� Sun Solaris� SUSE® Linux Enterprise Server� Windows 2003 Server� z/OS

ITIM RACF adapterITIM 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.

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

DAML over TCP/IP Started Task APPC Transactions

Defined as SPECIALor GROUP SPECIAL

Optional (to administer subpopulations)otherwise is executed with

RACF ID « ITIAGNT »

Tivoli IdentityManager Server

RACF SSLService Form

ADMINX

« RACF ID under whichrequests will be

processed » field onservice forrm is set to

« ADMINX »

z/OS Platform

Agent operatingin UNIX System

Services

RACF IDassigned to

agent is« ITIAGNT »

CommandProcessor

operating inAPPC/MVS

RACF ID usedfor processing

requests will be« ADMINX »


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 adapterThere is an ITDI-based LDAP adapter that can be installed on different platforms, including z/OS.

Complementing ITIM with ITDIWe 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.


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.

ITDIServices AssemblyLine

EventHandler

z/OS LDAP changelogevent handler polls the

changelog to look for RACFpassword change andstarts AssemblyLine

Connector posts passwordchange request to ITIM

over a secure connection

LDAP Connectorgets the password change

ITIMApplication Server

ITIMAgentAIX

ITIMAgent

WindowsXP

ITIM passwordsynch functionreceives the

synchronization requestand the user’s password isupdated for all accounts the

person owns

User changesRACF password

1

2

3

4

5

6


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.

11


11.1 Our sample configuration

Our sample configuration is shown in Figure 11-1.

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.

LDAPUserregistry

AIXWebSphere Application Server

browser

browser

Business Partner

customers

z/OS

WebSphere Application Server

CICS DB2

DDF

DB2 clientWindowsActive DirectoryKerberos KDC

RACF

z/OS LDAPUser registry

IBMTivoli

AccessManager

Kerberosauthentication

Hardware crypto

LDAPauthentication

EJBROLE

RACFSecurity

Corporation

WebSEALAuthentication

proxy

Linux Linux

Windows

Windows

Windows

SOAP Web service

11

22

55

5533

66

77

44

88

DMZ

IPSec VPNIP FilteringIDS…

Restricted Zone


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 securityAddressing 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 usersThe 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.

� 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 employeesBusiness 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.

CustomersCustomers 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 registriesThis section summarizes the logical user registries and the underlying products used in our sample configuration to authenticate users.

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.


One user registry at the Business Partner locationThe 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 locationWe 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).

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.

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.


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

LDAPUserregistry

AIXWebSphereApplicationServer

browser

browser

Business Partner

customers

z/OS

WebSphere ApplicationServer

CICS DB2

DDF

DB2 client

RACF

z/OS LDAPUser registry

IBMTivoli

AccessManager

Kerberosauthentication

Hardware crypto

LDAPauthentication

EJBROLE

RACFSecurity

Corporation

WebSEALAuthentication

proxy

Linux Linux

Windows

Windows

Windows

SOAP Web service

ITIM

ITDI

A

A

IPSec VPN

ITDI

11

22

33

WindowsActive DirectoryKerberos KDC


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.

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.

RACFThe 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 registryThe 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.

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.


� 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 registryThe 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.


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.

Business Partner LDAP user registry

BP private subtree

Subtree withpersons

authorized toCorporate

•ITDI watching changelog•ITDI access controlledby ACLs

TDI

BP userswith WAS/HTTPAuthentication

subtree

Corporate z/OS LDAP user registry

Provisioning/Maintenanceof BP entries

RACFcorporate

Corporatewith native

authenticationsubtree

Corporatewith

userpassword

Passwordchange

1ITDI on z/OS ITIM

z/OS GDBM

Z/OS SDBM

Customers

workflowStrips outattributes

•ITDI watching changelog

Password envelope

Password

2

3

4

55

7

6


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.

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

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.


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=usuid=wastomobjectclass=inetOrgPersonobjectclass=organizationalPersonobjectclass=topsn=tommycn=tompassword=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.)

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=usobjectclass=groupOfNamesobjectclass=topcn=groupcorp3member= uid=initial,c=usmember= uid=wastom,ou=wasusers,ou=corptdbm,o=itso,c=usmember= ...

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.

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.


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 authorizationAs 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 authorizationThis 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.

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.


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

browser

webSEAL

servlet EJB

JAAS LoginModule

orTAI

Request toWeb services

Web servicesrequestor

browser

BPLDAP

authentication

Business Partner

WASSOAPWeb

app

Web Serviceimplementation

connector

z/OS LDAP (TDBM or LDBM) ITDI

ITIM

LDAP users….

LDAP groupscn=BP_acme_roleAcn=BP_acme_roleBcn=BP_acme_roleC1

Authorizationdatabase

ACLsURL WAS– cn=BP_acme_roleA

cn=BP_ACME_roleBcn=BP_ACME_roleC

Role A – cn=BP_acme_roleARole B – cn=BP_ACME_roleBRole C – cn=BP_ACME_roleC

Web Container EJB Container

JAAC

Authorizationrequests

2

3

45

6

7

Corporation

8

TAM

4


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.


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


� 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:


The details of getting Linux certified against ISO 15408 are available at:


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




http://www.ibm.com/support/

http://www.ibm.com/support/

http://www.ibm.com/services/

http://www.ibm.com/services/



Index

Symbols_initACEE 105

Aabandon 95acceleration, RSA 86access control 6Access Control Environment Element 45Access Control List 94, 104Access Manager

... for Business Integration 200pdadmin 197Policy Proxy Server 197Policy Server 197Trust Association Interceptor 199Web Portal Manager 197

Access Manager Business Integration Host Edition 202Access Policy 3accessGroup 99accessRole 99account 210Accountability Policy 3ACEE 45–46, 230ACF2 44ACL 94, 104, 195, 227add 95ADDUSER 58Advanced Encryption Standard 9AES 9AIX 198, 205, 215ALL 53ALTER 47, 53ALTUSER 58ALWAYS 54AMBIHE 202anonymous 2AP 83Apache Web Server 198APDEDICATED 88APF (Authorized Program Facility) 19, 37–38APPC 215APPLDATA 64, 105–106, 170application layer firewall 126APVIRTUAL 88ASIS 188AssemblyLine 207, 209, 227asserted identity 109Asset Classification Policy 3AT-TLS 36, 132auditing 7, 38, 53AUDITOR 44, 55auditor 54authentication 6, 45Authentication Server 112

© Copyright IBM Corp. 2008. All rights reserved.

authorityKeyIdentifier 49authorization database 196authorization engine 194authorized program 37Authorized Program Facility (APF) 18, 37azn_creds_delet 203azn_decision_access_allowed 203azn_id_get_creds 203aznAccess 203aznAPI 171, 195aznAPI. 11aznCreds 203

BbasicConstraints 49BBO.SYNC 159, 167BBO.TRUSTEDAPPS 160bind 95, 100BIND 9 131binding 177biometrics 121BSM Control File 22

CCA 116Callback 161CallbackHandler 161Candidate-list 83CAPP 17CARS 200CBIND 159CCA 27CCF 80CDSA 28, 85CERT 131Certificate Authority 28, 116certificate expiration 118certificate map mode 173Certificate Name Filtering 46certificate revocation 118Certificate Revocation List (CRL) 118Certificate Revocation Lists (CRLs) 28CEX2A 82CEX2C 79Change Log notification 62changelog 227checksum 7Circuit level firewall 126CKDS 84Common Auditing and Reporting Services 200Common Criteria 16Common Cryptographic Architecture (CCA) 85commonName 92Communications Server Security Level 3 37

235

compare 95CONNECT 58CONTROL 47, 53Control Program 19Controlled Access Protection Profil 17controlled network 128controlled zone 127countermeasures 4CP 19CP Assist for Cryptographic Functions 79CPACF 79–80, 86CRAM-MD5 96, 98credential propagation 109CRL 28, 117, 180CRT 82crypt() 98CRYPTO 88Crypto Express 2 79cryptographic

coprocessor 21function support 80processors 80

Cryptographic Key Data Set 84CryptoVSE API 86CSIv2 158CSNDPKD 82CSNDPKE 82custom user registry 163, 173

DDAC 48data confidentiality 7Data Encryption Standard 9data integrity 7Data Security Monitor 51DATAGRAMFWD 131DEFAULT 55, 188DEFAULT login configuration 161delegation 6, 109, 115, 121delete 95demilitarized zone (DMZ) 127Denial of Service 124

multiple packet DoS 124single packet DoS 124

deployment descriptor 177DES 9, 81description 92DFSMS 48DFSORT ICETOOL 52DIAGNOSE 21DIGEST-MD5 96, 98digital certificate 42–43, 46DIGTCERT 49, 105DIGTCRIT 49, 106DIGTNMAP 49, 106DIGTRING 49DIRACC 55DIRSRCH 55Discretionary Access Control 48Distinguished Encoding Rules (DER) 65

DIT 93DMZ 128–129, 221DOMAIN 88domain 21, 83DSA 46, 120DSMON 51DUKPT 81dynamic packet filter firewall 126

EEAL 17EAR 168EIM 30, 106EIM Domain Controller 30, 107EJB method permission 164EJBROLE 50, 65, 168–169, 221, 230EMV 2000 81encryption 7End-to-End Accountability 10, 67Enterprise Identity Mapping 30, 106Enterprise System Architecture 15ESM 22Evaluation Assurance Level 17Event Handler 205EXECUTE 47EXOP 34, 59extended attribute 38external controlled zone 127External Security Manager 22, 41external zone 127EZB.NETACCESS 133

Ffacility name 39FAILURES 53, 55FC 3863 80federated repositories 163File Owner auditing flags 55File Security Packet 42FIPS 140-2 80firewall 125, 129firewall technologies 29Five-year PKI intermediate CA server certificate 119Five-year PKI IPSEC server (firewall) certificate 119Five-year PKI SSL server certificate 119FSOBJ 55FSP 42, 55FSSEC 56FTP 36, 114, 131

GGDBM 33, 59, 101, 217, 225, 227GEJBROLE 168, 221general instructions 14Generalized Security Services API (GSS-API) 29getCallerPrincipal 169getUserPrincipal 169Global Access Checking Table 51


group filter 173group ID map 173group member ID map 173GROUP profile 42groupOfNames 94, 97, 99groupOfUniqueNames 97, 99groupOfURLs 99group-OPERATIONS 54group-SPECIAL 54GSS-API 29, 115

Hhardware cryptography 24hardware interruption 14hash value 7HCD backend 32HCR7740 28HCR7750 28, 86HIPAA 75homeDirectory 96hostIDMap 119HP Unix 198, 205HP-UX 215HTTP 125, 157HTTPS 125hypervisor 19

Ii5/OS 206IBM 4753 81IBM Common Cryptography Architecture 27IBM DataPower 187IBM HTTP Server 198IBM Ported Tools for z/OS 25IBM SDK 85IBM Tivoli Directory Integrator 101IBM Tivoli Directory Server for z/OS 29ibm-dynamicGroup 99IBMJCECCA 159, 185IBMJSSE2 185ibm-nativeAuthentication 99ibm-nativeId 98, 229ibm-nestedGroup 100IBMPKCS11Impl 88IBMRRAP 175, 189ibm-staticGroup 99ICHPWX11 45ICSF 27, 49, 84ICTX 49, 59, 65, 68identification 6, 45identity assertion 6, 109, 165, 182identity mapping 105IDS 36, 132, 221IETF PKIX standards 117, 120Image profile 83inetOrgPerson 93, 97–98Integrated Cryptographic Service Facility 27Intel Common Data Security Architecture (CDSA) 28Internet threats 125

intrusion 124Intrusion Detection Services 132IP datagram 124IP Filtering 132, 221IPCOBJ 56IPSec 9, 132, 221IRR.ADMIN.EXTRACT.PWENV 64IRR.LDAP.REMOTE.AUTH 66IRR.RAUDITX 66IRRADU00 56IRRPassTicket 58isCallerInRole 169ISO 15408 16ISO 7498-2 6issuerAltName 49isUserInRole 169ITDI 44, 64, 191, 193, 204, 224ITDI connector 207ITDI event handler 208ITDI function component 208ITDI hook 208ITDI parser 208ITDI script 208ITDS 29, 31, 191, 193, 223ITIM 210, 225ITSEC 16IUCV connections 21

JJ2EE 25, 42, 50, 156, 175J2EE roles 167JAAS 160JAAS login module 161JAAS principal 170, 230JAAS subject 161JACC 168, 170, 175, 181, 221, 230JAR 168Java 25, 44, 58, 88Java Authentication and Authorization Services 160Java Authorization Contract for Containers 170Java Contract for Containers 168Java cryptographic service providers 85Java Message Service 158Java thread identity 164JAX-RPC 177JAX-WS 177JCA 157JCECCAKS 185JCECCARACFKS 185JCEKS 185JDBC 166, 207JDK 58JMS 157–158, 178, 180JMX 206JSec 58JSP 169junction 199JVM 157

Index 237

KKDC 12, 111, 222KERB segment 49, 106, 113Kerberos 8, 26, 29, 42–43, 49, 104–105, 111Kerberos forwardable tickets 115Kerberos Key Distribution Center 12, 107Kerberos pre-authentication 116Kerberos Realm 111KERBLINK 47, 106, 113, 222Key Distribution Center 26, 30key-controlled protection 15KeyUsage 49krbprincipalname 105

LLabelled Security Protection Profile 17Language Environment 44LDAP 8, 91, 120–121LDAP adapter 216LDAP attribute 92LDAP Data Interchange Format 94LDAP Directory Information Tree 93LDAP Directory Server 29LDAP entry 93LDAP entry Distinguished Name 94LDAP Native Authentication 98–99LDAP object class 92LDAP replication 34, 101LDAP schema 92LDAP suffix 94LDAP user registry 91ldapadd 60ldapdelete 60ldapmodify 60ldapsearch 60LDBM 33, 98, 209, 229LDIF 94libica 87Linux 19, 23, 198, 205, 215LIPKEY 30LoginContext 161LoginModule 161loginShell 96LOGOPTIONS 54Lotus Domino 160, 197low-address protection 15LPA 38LSPP 17LTPA 199LTPA_WEB 161

MMAC 48Mandatory Access Control 48Master Key 80, 83MD5 9, 98ME 82member 97Message Security Assist 80

Microsoft Active Directory 114, 197, 221, 223Microsoft Active Directory Application Mode 197Microsoft.NET 175minidisks 20MIT Kerberos V5 115MLS 42, 48, 52modify 95modifyDN 95MRA 17MSA 80Multilevel Security 42Multiple Virtual Storage 18mutual recognition arrangement 17MVS 18

NNAT 125national characters 45Native Authentication 33native authentication 209NETACCESS 133network

zones 128Network Address Translation 125Network Authentication Service 29Network Level Security 25network model 126network zone

controlled 128restricted 128secured 129uncontrolled 128

NEVER 55NFS 114NOFAIL 188NONE 47, 53, 188NOPASSWORD 131NOTIFY.LDAP.CONNEC 63NOTIFY.LDAP.GROUP 63NOTIFY.LDAP.USER 228NOUAUDIT 54Novell eDirectory 197n-year PKI browser certificate for extensions demonstra-tion 119

OOAM 201OASIS 176Object Authority Manager 201object reuse 16OCEP 28OCSF 28, 85OCSP 120–121ODBC 204OMPROUTE 36One-year PKI S/MIME browser certificate 119One-year PKI SSL browser certificate 119One-year SAF browser certificate 119One-year SAF server certificate 119


Online Certificate Status Protocol 120Online Certificate Status Protocol (OCSP) 28On-line list 83Open Cryptographic Enhanced Plug-in (OCEP) 28Open Cryptographic Service Facility 28Open Shortest Path First (OSPF) 36OpenSSH 25OpenSSH for z/OS 37OPERATIONS 54organizational tree 211organizationalPerson 93OS thread identity 164, 166OS/390 18, 41OSPF 36

OSPF MD5 36

Ppacket filter firewall 126page protection 15PAGENT 135PAM 96, 160PassTicket 42, 45PassTicket generator 45password 42–43, 45Password Enveloping 59password phrase 42, 45PASSWORD.ENVELOPE 64, 228PCICA 81PCICC 80PCI-X 80pdacld 203pdadmin 197PDAS 203persistent search 228person 92PKCS#11 85, 88PKCS#12 49PKCS#7 49, 63, 180PKDS 49, 84, 121, 185PKI 116PKITP 28PKIX 8Platform Level Security 25PlatformAccessControl 58PlatformAccessLevel 58PlatformReturned 58PlatformSecurityServer 58PlatformThread 58PlatformUser 58Pluggable Authentication Module 96pluggable mapping module 174Policy Agent 135Policy Director Authorization Services 203policy domain 4policy enforcer 196Policy Proxy Server 197Policy Server 197PORT 134PORTRANGE 134posixAccount 96

posixGroup 96PPT 51PR/SM 15, 18priority code 39Private Key Data Set 84PrivateCredentialPermission 161Privilege Policy 3privileged instructions 14PROCACT 56PROCAT 56PROCESS 56Program Control 131Program Property Table 51programmatic security 169Protected Object Namespace 195Protected Object Policy 195Pseudo Random Number Generator 81Public Key Algorithm 81Public Key Infrastructure 8, 116

QQueue number 83

RR_auditx 52, 66R_cacheserv 203R_GenSec 29R_gensec 58R_proxyserv 203R_tickerserv 58R_usermap 106RACDCERT 49RACF 28, 41RACF access list 104RACF adapter 215RACF Auditor auditing flags 55RACF Authorized Caller Table 51RACF Callable Services 44RACF Identity Cache 64RACF key ring 120, 159RACF Remote Authorization Provider 175RACF Remote Sharing Facility 44RACFEVNT 228racfPasswordEnvelope 64RACROUTE 22, 44RACROUTE REQUEST=AUTH 65RACROUTE REQUEST=VERIFY 69RDN 94READ 47–48, 53–54REALM 110, 113reason code 43Redbooks Web site 234

Contact us xiiireference number 69Regulatory Compliance Policy 3relative distinguished name 94remote auditing 31remote authorization 31, 64report writer 52

Index 239

resource manager 43, 198Responsibility Policy 3restricted 127restricted network 128restricted zone 127RESTRICTLOWPORTS 134retained key support 81return code 43reverse proxy 165, 198RFC 1510 8RFC 1823 8RFC 2025 30RFC 2246 8RFC 2251 8RFC 2328 36RFC 2401 9RFC 2410 9RFC 2459 8RFC 3377 8RMF backend 33RMI/IIOP 157–158, 178, 180, 230RMI_BOUND 174RMI_INBOUND 161, 230RMI_OUTBOUND 161router 126RRSF 44RSA 9, 46, 81, 120rshd 36, 114RunAs identity 164, 170RVARY 52

SSAF 44SAF classes 58SAF-based local registry 163SAML 180SASL 96SCEP 120SDBM 29, 33, 44, 49, 59, 97, 100, 209, 225search 95SECLABEL 48, 54Secure Socket Layer 8Secure Socket Layer (SSL) 28secured network 129secured zone 127security

policy 129Security Architecture 4Security Assertion Markup Language 180Security Information and Event Managemen 73security island 110security label 42Security level 3 36Security Server 28Security Target 17seeAlso 92sendmail 36SERVAUTH 48, 133

NETACCESS 133PORTACCESS 134

SERVER 159servlet 169SETROPTS 52SETROPTS LOGOPTIONS 56SHA 9, 80, 98SHA-256 80SIE 19SIEM 73, 192Simple Authentication and Security Layer 96simple bind 95Simple Certificate Enrolment Protocol 120Single Sign-On 199SKRBKDC 113smart card 121SMF 51–52SMF Data Unload Utility 56SMF record type 109 39SMF Type 80 52SMF type 80 188–189SMF Type 83 53SMF type 83 189SMF type-83 100SMTP 73sname 105SNMP 73, 206SNMPv3 36SOA 5, 192, 219SOAP 157, 176, 180, 186SOX 75SPECIAL 54SPKM-3 30, 105, 110SQL Injection 186SSH 37SSL 8, 80SSL Daemon 87SSL for VSE API 87SSL transactions 82SSL/TLS 104–105ST 17stack hardening 130standards 7Start Interpretive Execution 15stateful

inspection 126Statement of Integrity 18, 21storage protection 15subjectAltName 49subjectKeyIdentifier 49SUCCESS 53SUCCESSES 55Sun Java System Directory Server 197Sun Java System Web Server 198Sun Solaris 198, 206surName 92SWAM 160, 162Sync To OS Thread 167SYS1.LINKLIB 38SYS1.SVCLIB 38syslogd 39System Authorization Facility 44


System Integrity 18System SSL 28, 85

TTAI 165–166, 179, 199TAM 171, 191–192, 194TAM E-SSO 194TAM identity 172TAM JACC Provider 172TAM Java Runtime 172TAMBI 194, 200TAMeb 194, 198TAMOS 194Target of Evaluation 17TCIM 192TCPIP.PROFILE 133TCSEC 16TDBM 33, 98, 209, 229TelephoneNumber 92telnet 36, 114TFIM 191–192TGS 113Threat Assessment Policy 3Ticket Granting Server 112TIM 191, 193Tivoli Access Manager 191–192, 194, 221Tivoli Compliance Insight Manager 75Tivoli Directory Integrator 191, 193, 204Tivoli Directory Server 191, 193Tivoli Federated Identity Manager 191–192Tivoli Identity Manager 191, 193, 210Tivoli Identity Manager role 212Tivoli Security Compliance Manager 191–192Tivoli Security Operations Manager 73, 191–192TKDS 85TLS 8TN3270 36TOE 17Token Key Data Set (TKDS) 85Top Secret 44Transaction Level Security 25Transport Layer Security (TLS) 28trust 4Trust Association Interceptor 165, 199Trust Policy 3, 28Trusted Proxy Server 165Trusted Third Party 107TSOM 191–192TTP 107Two-year PKI Authenticode 119Two-year PKI browser certificate for authenticating to z/OS 119Two-year PKI Windows logon certificate 119

UUACC 47, 51UAUDIT 54UDX 81–82uid 97, 105, 229

uidNumber 96unbind 95, 100uncontrolled network 128uncontrolled zone 127uniqueMember 97UNIX 198UPDATE 47–48, 53–54user filter 173user ID map 173user identity 104USER profile 42user registry 108username token 182userPassword 64, 92userPassword encryption 98

VVirtual Private Network 126VPN 80, 126VSE Control File 22

WWAR 168Web Portal Manager 197Web Services 25Web Services Description Language 177WEB_INBOUND 162, 174, 230WebSEAL 160, 166, 172, 198–199, 221, 232

junction 199Trust Association Interceptor 199

WebSEAL SSO 172WebSphere Application Server 50, 155

administration 171authorization 167component 168credential 172deployment 166PDPrincipal 166policy 166

WebSphere Application Server 6 165WebSphere MQ 200Windows 198, 206, 215Windows XP 114workflow 213WS-Authorization 181WSDL 177, 186WS-Privacy 181WSS 176WS-SecureConversation 181WS-SecurityPolicy 181WS-Trust 181

XX.500 8X.500 directory distinguished name 230X.500 distinguished name 104X.500 name 56X.500 subject’s name 105

Index 241

X.509 8, 42, 46, 49X.509 token 182X.509 V2 Certificate Revocation List 117X.509 V3 certificate 116X.509 V3 digital certificate 119XML 52XML Denial of Service 186XML encapsulation 186XML-formatted output 57

Zz/OS 206z/OS Cryptographic Services 27z/OS IBM Ported Tools 37z/OS Identity Cache 30z/OS Integrated Security Services 29z/OS Integrated Security Services LDAP server 31z/OS LDAP 26z/OS LDAP client 31z/OS PKI Services 25, 28z/OS Security Level 3 35z/OS Security Server 28z/OS UNIX 55z/OS UNIX System Services 52z/OS V1R9 85z/VM 15, 17, 19z/VM directory 20z/VSE 22z90crypt 87zcrypt 87zSecure 191–192zSecure Admin 70zSecure Alert 77zSecure Audit 76zSecure CICS Toolkit 72zSecure Command Verifier 78zSecure Visual 71


(0.2”spine)0.17”<

->0.473”

90<->

249 pages





®

SG24-7344-00 ISBN 0738431486

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.

For more information:ibm.com/redbooks

®

Designing forSolution-Based Securityon 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

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.

Back cover




designing for solution-based security on z/os · designing for solution-based security on z/os...

Documents