z/os Connect Security

Transcription

1 IBM Advanced Technical Skills ZCONN1 WebSphere Application Server Liberty Profile Connect Security

2 Agenda Overview of Connect Security Security features for designers and architects. Securing our Lab Implementation Details for the security administrator. Features 2

3 Big Picture View of Mobile Environment and Connect provides the mobile environment with a secure interface to applications and data. We anticipate the following to be a common architectural model: Firewall Access s Firewall Proxy Proxy Server Server Systems of Engagement (e.g. IBM MobileFirst Platform, WebSphere,etc.) Linux on System z, or Other Internet DMZ Connect and Systems of Record (e.g.,, Corporate intranet Shift Right 3

4 Connect Security Features Connect and the Liberty Profile utilize to provide mainframe quality security. Connect Remote Remote Liberty Profile Remote clients include Systems of Engagement like IBM MobileFirst Platform, other mid-tier devices, or even other mainframe programs. SAF Confidentiality 4

5 Connect Security Features: Confidentiality Protecting the conversation between client and server. Remote Remote Connect Secure Sockets Layer (SSL) Liberty Profile Also known as Transport Layer Security (TLS). Java-based keyfiles and certificates SAF Quick and easy. SAF keyrings and certificates Under security admin control. 5 Authentication

6 Connect Security Features: Authentication Making the client prove its identity. Basic Authentication Remote Remote Connect LTPA Token WebSphere credentials in a cookie. Liberty Profile Certificate Authentication Mapping the client's certificate to a local userid. Userid/password in the http header SAF Trust Association Interceptor (TAI) For customized authentication solutions. Registry 6

7 Connect Security Features: Registries Where the clients are defined. Remote Remote basicregistry Define users, groups in server.xml. Connect SAF Liberty Profile RACF, CA-ACF2, CA-Top Secret. LDAP Local or remote. LDAP SAF Authorization 7

8 Connect Security Features: Authorization Controlling what the authenticated client can do. Remote Remote APPL To use Connect. Connect EJBROLE To use Connect. Liberty Profile Authorization Interceptor Using groups for finer grained authority. SAF Authorization 8

9 Connect Security Features: Authorization Controlling what Connect and can do. CBIND For to register with Connect's WOLA. Remote Remote Connect SERVER For Liberty Profile to use authorized services, e.g. SAF authorization, WOLA, etc. Liberty Profile SAF Propagation 9

10 Connect Security Features: Propagation What identity is passed to? Remote Remote The Link Server task. Connect The remote client. Liberty Profile An identity asserted by the remote client. SAF Audit 10

11 Connect Security Features: Audit What record is there of security events? Remote Remote Liberty log files. Connect SMF type 80. Authentication, Authorization (EJBROLE, CBIND, APPL, TTRN, SURROGAT). Liberty Profile SAF SMF Lab so far 11

12 A Sample Security Scenario Security requirements vary based upon the nature of the application. This diagram might serve as a starting point for further discussion. SSL IBM Security Access Manager for Mobile SSL Auth/Proxy Auth/Proxy Server Server SSL Internet ID/PW= 12 IBM Security Access Manager for Web SSL Systems of Engagement (e.g. IBM MobileFirst Platform, WebSphere,etc.) Linux on System z, or Other Connect and Systems of Record (e.g.,, Corporate intranet DMZ cert= SSL LTPA Token=

13 Securing our Lab Implementation Unit 2 Lab 13

14 The RACF Commands from Unit 2 Lab In Unit 2 Lab you defined the Server and Angel userids and a guest userid, and groups to own them. USER1.WAS.CNTL(ZCRACF1): ADDGROUP LIBGRP OMVS(AUTOGID) OWNER(SYS1) ADDGROUP WSGUESTG OMVS(AUTOGID) OWNER(SYS1) ADDUSER LIBANGE DFLTGRP(LIBGRP) OMVS(AUTOUID HOME(/u/libange/) PROGRAM(/bin/sh)) NAME('LIBERTY ANGEL') NOPASSWORD NOOIDCARD ADDUSER LIBSERV DFLTGRP(LIBGRP) OMVS(AUTOUID HOME(/u/libserv/) PROGRAM(/bin/sh)) NAME('LIBERTY SERVER') ALTUSER LIBSERV PASSWORD(LIBSERV) NOEXPIRED ADDUSER FRED DFLTGRP(LIBGRP) OMVS(AUTOUID HOME(/u/fred/) PROGRAM(/bin/sh)) NAME('USER FRED') ADDUSER WSGUEST RESTRICTED DFLTGRP(WSGUESTG) OMVS(AUTOUID HOME(/u/wsguest) PROGRAM(/bin/sh)) NAME('UNAUTHENTICATED USER') NOPASSWORD NOOIDCARD Continued on next page. 14 Angel and server

15 Liberty Profile Started Tasks The Liberty Profile consists of one or more servers and optionally one Angel. Angel Server Applications like Connect may need access to system services like SAF, WLM, dump, and WOLA. Access is not the default. The Liberty Server is where Connect runs. The Angel Process runs in an authorized key and provides facilities to Liberty Server Processes to load and access system services in a way that protects the integrity of the operating system. The Angel provides SAF controlled access to services. More Unit 2 15

16 The RACF Commands from Unit 2 Lab (continued) You also assigned the Server and Angel userids to the started procedures. RDEFINE STARTED BBGZSRV.* UACC(NONE) - STDATA(USER(LIBSERV) GROUP(LIBGRP) PRIVILEGED(NO) TRUSTED(NO) TRACE(YES)) RDEFINE STARTED BBGZANGL.* UACC(NONE) STDATA(USER(LIBANGE) GROUP(LIBGRP) PRIVILEGED(NO) TRUSTED(NO) TRACE(YES)) SETROPTS RACLIST(STARTED) REFRESH After you built the server, you made LIBSERV a PROTECTED userid. ALTUSER LIBSERV NOPASSWORD NOOIDCARD Unit 3 Lab 16

17 The RACF Commands from Unit 3 Lab In Unit 3 Lab you permitted the Liberty Server to use several authorized services protected by SERVER class profiles. USER1.WAS.CNTL(ZCRACF2): RDEFINE SERVER BBG.ANGEL UACC(NONE) OWNER(SYS1) PERMIT BBG.ANGEL CLASS(SERVER) ACCESS(READ) ID(LIBSERV) RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM UACC(NONE) OWNER(SYS1) PERMIT BBG.AUTHMOD.BBGZSAFM CLASS(SERVER) ACCESS(READ) ID(LIBSERV) RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.SAFCRED UACC(NONE) PERMIT BBG.AUTHMOD.BBGZSAFM.SAFCRED CLASS(SERVER) ACCESS(READ) ID(LIBSERV) RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.ZOSWLM UACC(NONE) PERMIT BBG.AUTHMOD.BBGZSAFM.ZOSWLM - CLASS(SERVER) ACCESS(READ) ID(LIBSERV) Continued on next page. More Unit 3 17

18 The RACF Commands from Unit 3 Lab (continued) Server class profiles control the use of the Angel, SAF, WLM, RRS, SVC dump, the security prefix and WOLA. RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.TXRRS UACC(NONE) PERMIT BBG.AUTHMOD.BBGZSAFM.TXRRS - CLASS(SERVER) ACCESS(READ) ID(LIBSERV) RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.ZOSDUMP UACC(NONE) PERMIT BBG.AUTHMOD.BBGZSAFM.ZOSDUMP - CLASS(SERVER) ACCESS(READ) ID(LIBSERV) RDEFINE SERVER BBG.SECPFX.BBGZDFLT UACC(NONE) PERMIT BBG.SECPFX.BBGZDFLT - CLASS(SERVER) ACCESS(READ) ID(LIBSERV) RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.WOLA UACC(NONE) OWNER(SYS1) PERMIT BBG.AUTHMOD.BBGZSAFM.WOLA CLASS(SERVER) ACCESS(READ) ID(LIBSERV) Continued on next page. More Unit 3 18

19 The RACF Commands from Unit 3 Lab (continued) An EJBROLE protects Connect. RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.LOCALCOM UACC(NONE) OWNER(SYS1) PERMIT BBG.AUTHMOD.BBGZSAFM.LOCALCOM CLASS(SERVER) ACCESS(READ) ID(LIBSERV) RDEFINE SERVER BBG.AUTHMOD.BBGZSCFM UACC(NONE) OWNER(SYS1) PERMIT BBG.AUTHMOD.BBGZSCFM CLASS(SERVER) ACCESS(READ) ID(LIBSERV) RDEFINE SERVER BBG.AUTHMOD.BBGZSCFM.WOLA UACC(NONE) OWNER(SYS1) PERMIT BBG.AUTHMOD.BBGZSCFM.WOLA CLASS(SERVER) ACCESS(READ) ID(LIBSERV) SETROPTS RACLIST(SERVER) REFRESH RDEFINE EJBROLE ** OWNER(SYS1) UACC(NONE) PERMIT ** CLASS(EJBROLE) RESET SETROPTS RACLIST(EJBROLE) REFRESH Continued on next page. More Unit 3 19

20 The RACF Commands from Unit 3 Lab (continued) A CBIND profile controls which Listener Tasks can register with WOLA. An APPL profile protects Connect. RDEFINE CBIND BBG.WOLA.GROUP.NAME2.NAME3 UACC(NONE) OWNER(SYS1) PERMIT BBG.WOLA.GROUP.NAME2.NAME3 CLASS(CBIND) ACCESS(READ) ID(USER1) PERMIT BBG.WOLA.GROUP.NAME2.NAME3 CLASS(CBIND) ACCESS(READ) ID(X) SETROPTS RACLIST(CBIND) REFRESH RDEFINE APPL BBGZDFLT UACC(NONE) OWNER(SYS1) PERMIT BBGZDFLT CLASS(APPL) RESET PERMIT BBGZDFLT CLASS(APPL) ACCESS(READ) ID(WSGUEST) RALT APPL BBGZDFLT UACC(READ) SETROPTS RACLIST(APPL) REFRESH Hardening Connect 20

21 WebSphere Optimized Local Adapter (WOLA) Security The Liberty Profile defines the WOLA adapter in the server.xml. The WOLA adapter is protected by a CBIND profile in RACF. Connect The CBIND profile is based on the WOLA definition. The Link Server task ID of the partners must be permitted to use the adapter. The Link Server task ID is the userid which starts the Link Server task. WOLA Liberty Profile server.xml: <zoslocaladapters wolagroup="group" wolaname2="name2" wolaname3="name3" /> RACF commands: RDEFINE CBIND BBG.WOLA.GROUP.NAME2.NAME3 UACC(NONE) OWNER(SYS1) PERMIT BBG.WOLA.GROUP.NAME2.NAME3 CLASS(CBIND) ACCESS(READ) ID(USER1) PERMIT BBG.WOLA.GROUP.NAME2.NAME3 CLASS(CBIND) ACCESS(READ) ID(X) SETROPTS RACLIST(CBIND) REFRESH Local level 21

22 Hardening Connect with SAF security. A SAF keyring/cert for SSL/TLS. SAF as the User Registry. Enabling Basic or Certificate Authentication. An EJBROLE to protect Connect. The Authorization Interceptor. Passing an Identity to. SSL 22

23 Using a SAF keyring/cert for SSL/TLS SAF keyrings are under the control of the SAF administrator. server.xml: Connect Liberty Profile The Server (LIBSERV) owns the keyring. Digital ring information for user LIBSERV: Ring: >Keyring.LIBERTY< Certificate Label Name DefaultCert.LIBERTY Cert Owner USAGE ID(LIBSERV) PERSONAL LibertyCA.LIBERTY CERTAUTH CERTAUTH <featuremanager>.. <feature>ssl-1.0</feature> </featuremanager> <keystore id="defaultkeystore" password="liberty"/> <ssldefault sslref="defaultsslsettings" /> <ssl id="defaultsslsettings" keystoreref="celldefaultkeystore" truststoreref="celldefaulttruststore" clientauthenticationsupported="false" clientauthentication="false"/> <keystore id="celldefaultkeystore" location="safkeyring:///keyring.liberty" password="password" type="jceracfks" filebased="false" readonly="true" /> <keystore id="celldefaulttruststore" location="safkeyring:///keyring.liberty" password="password" type="jceracfks" filebased="false" readonly="true" /> Registry 23

24 Using SAF as the User Registry server.xml: safregistry uses the SAF database to authenticate clients. safauthorization uses the SAF database for role checking using the EJBROLE class. unauthenticateduser= WSGUEST uses the SAF userid WSGUEST for unauthenticated requests. profileprefix= BBGZDFLT prefixes EJBROLE profile checks with BBGZDFLT. The profileprefix value will also be used as the APPL name for the server. The unauthenticateduser userid must have READ access to the APPL name. <featuremanager>.. <feature>zossecurity-1.0</feature> </featuremanager> <basicregistry id="basic1" realm="zosconnect"> <user name="fred" password="fredpwd" /> </basicregistry> <authorization-roles id="zos.connect.access.roles"> <security-role name="zosconnectaccess"> <user name="fred"/> </security-role> </authorization-roles> <safregistry id="saf" /> <safauthorization id="saf" /> <safcredentials unauthenticateduser="wsguest" profileprefix="bbgzdflt" /> Authentication 24

25 Enabling Basic or Certificate Authentication cert, please. Connect Connect Huh? server.xml: clientauthenticationsupported= true the server prompts for a client cert in the SSL handshake. clientauthentication= true requires that the client have a client cert, or the SSL handshake will fail, and the conversation end. allowfailovertobasicauth= true the server reverts to the userid/password prompt if clientauthentication= false or the client has no certificate. <webappsecurity allowfailovertobasicauth="true" /> <ssldefault sslref="defaultsslsettings" /> <ssl id="defaultsslsettings" keystoreref="celldefaultkeystore" truststoreref="celldefaulttruststore" clientauthenticationsupported="false" clientauthentication="false"/> <keystore id="celldefaultkeystore" location="safkeyring:///keyring.liberty" password="password" type="jceracfks" filebased="false" readonly="true" /> <keystore id="celldefaulttruststore" location="safkeyring:///keyring.liberty" password="password" type="jceracfks" filebased="false" readonly="true" /> Authorization 25

26 An EJBROLE to protect Connect server.xml: The Connect application requires the user have role zosconnectaccess. The default profileprefix= BBGZDFLT. The default profile pattern is: %profileprefix%.%resource%.%role%. This makes the EJBROLE name: BBGZDFLT.zos.connect.access.roles.zos ConnectAccess To change the profile pattern, see next slide <featuremanager>.. <feature>zossecurity-1.0</feature> </featuremanager> <authorization-roles id="zos.connect.access.roles"> <security-role name="zosconnectaccess"> <user name="fred"/> </security-role> </authorization-roles> <safregistry id="saf" /> <safauthorization id="saf" /> <safcredentials unauthenticateduser="wsguest" profileprefix="bbgzdflt" /> RACF commands: RDEFINE EJBROLE BBGZDFLT.zos.connect.access.roles.zosConnectAccess OWNER(SYS1) UACC(NONE) PE BBGZDFLT.zos.connect.access.roles.zosConnectAccess CLASS(EJBROLE) ID(FRED) ACCESS(READ) Profile pattern 26

27 Controlling the EJBROLE profile pattern server.xml: The safrolemapper statement specifies the EJBROLE profile pattern. The default profile pattern: %profileprefix%.%resource%.%role%. <featuremanager>.. <feature>zossecurity-1.0</feature> </featuremanager> The default EJBROLE profile: BBGZDFLT.zos.connect.access.roles.zos <safregistry id="saf" /> ConnectAccess You can control the profile pattern, for example: <safauthorization id="saf" /> <safcredentials unauthenticateduser="wsguest" profileprefix="bbgzdflt" /> <safrolemapper profilepattern="%profileprefix%.%role%" touppercase="false" /> RACF commands: RDEFINE EJBROLE BBGZDFLT.zosConnectAccess OWNER(SYS1) UACC(NONE) PE BBGZDFLT.zosConnectAccess CLASS(EJBROLE) ID(xxxx) ACCESS(READ) Front door 27

28 The EJBROLE as front door. The zosconnectaccess EJBROLE protects the front door to Connect. But more access granularity is needed. zosconnectaccess? YES Authority to LIST, START, STOP, INVOKE, get STATISTICS for all RESTful Services. NO All or Nothing NO Authority RACF commands: RDEFINE EJBROLE BBGZDFLT.zos.connect.access.roles.zosConnectAccess OWNER(SYS1) UACC(NONE) PE BBGZDFLT.zos.connect.access.roles.zosConnectAccess CLASS(EJBROLE) ID(FRED) ACCESS(READ) Authorization Interceptor 28

29 Authorization Interceptor Provides three levels of authority for users of your Connect services: Administrator: the authority to query services, perform operational tasks on them, and invoke them. Operations: the authority to perform tasks on services such as stop, start, etc. but no authority to invoke services. Invoke: the authority to invoke services, but no other authority. Represented by membership in groups named in the server.xml. Defined at the Connect global level or for individual services. Global level 29

30 Implementing the Authorization Interceptor server.xml: At the global level: Users in RACF group GADMIN have Administrator authority at the global level. Users in RACF group GOPERS have Operations authority at the global level. Users in RACF group GINVOKE have Invoke authority at the global level. <zosconnectmanager globaladmingroup="gadmin" globaloperationsgroup="gopers" globalinvokegroup="ginvoke" globalinterceptorsref="interceptorlist_g" /> <authorizationinterceptor id="auth" /> <zosconnectinterceptors id="interceptorlist_g" interceptorref="auth,audit"/> RACF commands: ADDGROUP GADMIN OMVS(AUTOGID) ADDGROUP GOPERS OMVS(AUTOGID) ADDGROUP GINVOKE OMVS(AUTOGID) CONNECT USER1 GROUP(GADMIN) CONNECT FRED GROUP(GINVOKE) Service level 30

31 Implementing the Authorization Interceptor At the service level: Users in RACF group SADMIN have Administrator authority at the local level. Users in RACF group SOPERS have Operations authority at the local level. Users in RACF group SINVOKE have Invoke authority at the local level. server.xml: <zosconnectservice id="" invokeuri="/mybackend" servicename="-backend" dataxformref="xformjson2byte" serviceref="wola" admingroup="sadmin" operationsgroup="sopers" invokegroup="sinvoke" /> Service level takes precedence over Global. RACF commands: ADDGROUP SADMIN OMVS(AUTOGID) ADDGROUP SOPERS OMVS(AUTOGID) ADDGROUP SINVOKE OMVS(AUTOGID) CONNECT USER1 GROUP(SADMIN) CONNECT FRED GROUP(SINVOKE) Passing an identity 31

32 Passing the 's Identity to SIP: server.xml: <zoslocaladapters usecicstaskuserid="true" wolagroup="group" wolaname2="name2" wolaname3="name3" /> Passes the SAF identity of the Connect client to. Connect WOLA SEC=Y XTRAN=YES XUSER=YES security enabled. Liberty Profile Transactions protected. Link Server's userid checked for surrogate authority to the passed userid. Starting the Link Server task (BBOC): BBOC START_TRUE BBOC START_SRVR RGN=REG DGN=GROUP NDN=NAME2 SVN=NAME3 SVC=* MNC=1 MXC=10 TXN=N SEC=Y REU=N TRC=1 uses the passed userid instead of the Link Server task userid. Propagation Checklist 32

33 RACF Checklist for Passing an Identity to The Link Server ID needs: READ access to the CBIND profile: BBG.WOLA.GROUP.NAME2.NAME3 READ access to TTRN profiles BBOC and BBO$ (Link server task) READ access to SURROGAT profile <passedid>.dfhstart The identity being flowed/asserted needs: READ access to TTRN profile BBO# (Link invocation task) READ access to EJBROLE profile: BBGZDFLT.zos.connect.access.roles.zosConnectAccess Time for Unit 4 Lab 33