Unit 4 - zOS Connect Security...Unit 4 – z/OS Connect Security Unit 4 - 4 © 2014 IBM Corporation IBM Americas Advanced Technical Skills Gaithersburg, MD 4 z/OS Connect Security

Unit 1a - Overview

Unit 1a - 1

© 2014 IBM CorporationIBM Advanced Technical Skills

ZCONN1WebSphere Application Server Liberty Profile z/OS

z/OS Connect Security

WebSphere Application Server Liberty Profile z/OS

Unit 4 – z/OS Connect Security


Unit 4 - 2

© 2014 IBM CorporationIBM Americas Advanced Technical Skills

Gaithersburg, MD2

Agenda

Features …

Overview of z/OS Connect SecuritySecurity features for designers and architects.

Securing our Lab ImplementationDetails for the security administrator.

We'll begin by discussing how the Liberty Profile and z/OS connect provide the fundamental services needed by any secure application. Confidentiality, authentication, authorization, support for various registries, propagation and audit will be the topics. These will enable us to consider z/OS Connect in the context of the enterprise environment.

Next we'll discuss the security definitions necessary to implement z/OS Connect in the most secure fashion. Some of these were defined in Unit 2 and Unit 3 labs. The rest we'll be defining in the Unit 4 lab.


Unit 4 - 3


Gaithersburg, MD3

Big Picture View of Mobile Environment and z/OSz/OS Connect provides the mobile environment with a secure interface to z/OS applications and data. We anticipate the following to be a common architectural model:

Shift Right…

Internet

Access Clients

Proxy

Server

Proxy

Server

z/OS Connect

and Systems of Record

(e.g. CICS,

IMS, Batch

Systems of Engagement(e.g. IBM MobileFirst Platform, WebSphere,etc.)

Firewall Firewall

Linux on System z, z/OS or Other

z/OS

Corporate intranetDMZ

The big picture view of z/OS Connect has it safely in the corporate intranet, behind Systems of Engagement consisting of traditional WebSphere applications or mobile infrastructure support like IBM MobileFirst Platform, or other applications and servers. z/OS Connect resides on the same LPARs with Systems of Record like CICS, IMS, DB2 and Batch Processes.

In front of the corporate intranet will be a reverse proxy server, long used by Internet facing servers to proxy client requests and provide isolation. In many environments it's the place where authentication of the client takes place.

For now, we will shift our focus to the right hand side of this slide and concentrate on the relationship between the Systems of engagement, z/OS Connect and the enterprise applications. Later we will return to the big picture view and put what we've talked about in context.


Unit 4 - 4


Gaithersburg, MD4

z/OS Connect Security Featuresz/OS Connect and the Liberty Profile utilize z/OS to provide mainframe quality security.

Confidentiality …

Liberty Profile

z/OS Connect

CICSCICS

IMSIMS

BatchBatch

z/OS

SAF

Remote clients include Systems of Engagement like

IBM MobileFirst Platform,

other mid-tier devices, or even other mainframe

programs.

Remote

Client

Remote

Client

From z/OS Connect's perspective, the remote client is the System of Engagement or other servers in the enterprise. That's not to say that z/OS Connect will never know who the real end user with the cell phone, tablet or PC is, just that z/OS Connect won't talk directly to the end usert, but to intermediate systems (remote clients) passing requests on behalf of the end user. The remote client must authenticate to z/OS Connect and have a trusted relationship in order to pass requests.

Similarly, z/OS Connect must have a trusted relationship with the back-end enterprise applications that it passes requests to. The trusted relationship is based on authentication and permissions.

Since z/OS Connect and the enterprise applications reside on the z/OS operating system, it's most likely that security services will be provided by the System Authorization Facility (SAF) which includes any of the three external security managers for z/OS, namely RACF, CA-Top Secret and CA-ACF2. But z/OS Connect can also work with LDAP, like the distributed platforms do.


Unit 4 - 5


Gaithersburg, MD5

z/OS Connect Security Features: Confidentiality

Authentication …

SAF

Secure Sockets Layer (SSL)

● SAF keyrings and certificates

● Java-based keyfiles and certificates

“Protecting the conversation between client and server.”

Remote

Client

Remote

Client

Quick and easy.

Under security admin control.

Liberty Profile

z/OS Connect

CICSCICS

IMSIMS

BatchBatchz/OS

Also known as Transport Layer Security (TLS).

To protect the data flowing between the client and server we need to encrypt the data stream. Secure Sockets Layer (SSL), now largely replaced by Transport Layer Security (TLS) is the most successful and widely supported protocol for doing that. The protocol is still referred to as SSL by most folks. We'll refer to TLS and SSL collectively as SSL.

SSL requires the server to present its certificate to the client, which the client verifies using a signer certificate trusted by the client. If the verification completes successfully, the client knows the server is authentic and not an imposter. Optionally the server can require the client present its certificate which the server verifies using a signer certificate trusted by the server. That's called client certificate authentication and we'll talk about that later.

The Liberty Profile supports SSL, and supports storing the certificates either in a keystore/truststore in the file system or in a keyring in the SAF database. Resources in the SAF database are under the control of the SAF administrator.

When the Liberty server is built, a self-signed cert is created in the file system, which enables quick and easy setup of SSL for the server. It's good enough to get you started, but storing the certificates in SAF is more secure.


Unit 4 - 6


Gaithersburg, MD6

z/OS Connect Security Features: Authentication

Registry…

● Client Certificate Authentication

● Trust Association Interceptor (TAI)

“Making the client prove its identity.”

● Basic Authentication

● LTPA TokenWebSphere credentials in a cookie.

Mapping the client's certificate to a local userid.

For customized authentication solutions.

Userid/password in the http header

Liberty Profile

z/OS Connect

CICSCICS

IMSIMS

BatchBatchz/OS

Remote

Client

Remote

Client

SAF

Authentication means making the client prove its identity. Authentication is key to establishing the trusted relationship between the client and server. Since the client of z/OS Connect is in fact another server rather than a person, the typical userid and password entered on a login page will not be used. This is because storing a userid and password on a remote server has security issues, like who has access to them, and what do we do when the password expires. We use a userid and password for most of our labs so you can see that authentication is taking place, but in a production environment we would either rely on client certificate authentication, an LTPA token or a Trust Association Interceptor (TAI).

Client certificate authentication is where server requires the client present its certificate which the server verifies using a signer certificate trusted by the server. The server then maps the client certificate to a local (SAF) userid and then treats the client as authenticated, just as if the client had used a userid and pasword.

Once the client is authenticated, the Liberty server creates an LTPA Token for the client. The LTPA Token is a trusted, encrypted token (a cookie) containing the client's credentials. On subsequent calls, if the LTPA token is presented to the Liberty server by the client, the client will be treated as authenticated. WebSphere, the IBM Security Access Manager for Web, DataPower and WebSEAL all support the LTPA token format, which provides a mechanism for flowing the credentials of the end user if required.

For support of other authentication requirements or credentials, the TAI provides a pluggable interface for custom authentication processing.


Unit 4 - 7


Gaithersburg, MD7

z/OS Connect Security Features: Registries

Authorization …

● SAF

“Where the clients are defined.”

● basicRegistryDefine users, groups in server.xml.

Remote

Client

Remote

Client

Liberty Profile

z/OS Connect

CICSCICS

IMSIMS

BatchBatchz/OS

SAF

RACF, CA-ACF2, CA-Top Secret.

LDAP

● LDAPLocal or remote.

Whether the client is authenticated using a client cert, an LTPA token or a userid and password, the client must exist in a user database, also known as a registry.

The basicRegistry is a very simple registry implemented in the server.xml. It's quick and easy to setup and great for testing, but it's probably too rudimentary to meet your production requirements. We used it in Unit 2 and Unit 3 labs.

SAF is the native security database for z/OS. In some high value applications like banking, it's possible that your end users will be defined in SAF. But in most cases the identity that z/OS Connect will check will be that of the trusted server which calls z/OS Connect.

Another choice for a registry, and the most likely registry used on non-z/OS platforms is LDAP. Traditional WebSphere has the ability to map an LDAP distinguished name plus the LDAP server name, together called a Distinguished Identity, into a local SAF identity. This capability, called Identity Mapping, is currently being developed for the Liberty Profile.


Unit 4 - 8


Gaithersburg, MD8

z/OS Connect Security Features: Authorization

Authorization …

● EJBROLE

“Controlling what the authenticated client can do.”

● APPL

To use z/OS Connect.

To use z/OS Connect.

● Authorization InterceptorUsing groups for finer grained authority.

Liberty Profile

z/OS Connect

CICSCICS

IMSIMS

BatchBatchz/OS

Remote

Client

Remote

Client

SAF

Once the remote client has been authenticated, the next step is authorization, where z/OS Connect determines if the remote client has the authority to invoke/perform the service that it has requested. There are several checks which can be made by the Liberty server or z/OS Connect, depending on how you configure your implementation.

A SAF profile in the APPL class controls which users (once authenticated) the Liberty server will accept requests from. The APPL profile is the same as the security prefix you have chosen, the default is BBGZDFLT. Since the APPL profile is redundant with the EJBROLE profile, many implementations set the APPL profile to a UACC of READ.

The EJBROLE profile controls which users can get to z/OS Connect or other applications running on the Liberty server. If an application has an EJBROLE, that profile is checked after the user is authenticated to see if the user has READ access. If the user has access, the application is invoked. If not, the http status 403 is returned to the user.

The Authorization Interceptor is a concept unique to z/OS Connect. It implements more granular authority for the z/OS Connect user, but it does it without the use of additional EJBROLE profiles. Instead, it uses the user's membership in a group to determine if the user has administrative, operational, invoke or no authority to services provided by z/OS Connect.


Unit 4 - 9


Gaithersburg, MD9

z/OS Connect Security Features: Authorization

Propagation …

● SERVER

“Controlling what z/OS Connect and CICS can do.”

● CBIND For CICS to register with z/OS Connect's WOLA.

For Liberty Profile to use z/OS authorized services, e.g. SAF authorization, WOLA, etc.

Liberty Profile

z/OS Connect

CICSCICS

IMSIMS

BatchBatchz/OS

SAF

Remote

Client

Remote

Client

In addition to security protecting against a malicious client, Liberty protects against accidental misconfiguration or intentional access to or from the Liberty server or some of its trusted partners.

The WebSphere Optimized Local Adapter is a cross memory communications path created withing the Liberty server for the purpose of communicating with a CICS region. To make sure it's the correct CICS region, registration of the region must take place and a SAF CBIND profile controls which CICS Link Server tasks may register with a particular WOLA. This protects, for example, against the production CICS registering with a test z/OS Connect.

There are some sensitive z/OS services available to the Liberty server, but access authority is required to use them.


Unit 4 - 10


Gaithersburg, MD10

z/OS Connect Security Features: Propagation

Audit …

“What identity is passed to CICS?”

● The CICS Link Server task.

Liberty Profile

z/OS Connect

CICSCICS

IMSIMS

BatchBatchz/OS

SAF

Remote

Client

Remote

Client

● An identity asserted by the remote client.

● The remote client.

After authentication of the remote client takes place, and authorization checks are made to ensure that the remote caller has access to the server and application, the z/OS Connect application is invoked and runs under the identity of the remote client.

When a back end service like CICS is invoked through a Liberty service like WOLA, we have options on what identity CICS associates with the request. A back end service like CICS has its own set of authentication and authorization checks to make, just as the Liberty server did.

In the most simple setup, the CICS Link Server task processes all requests using the identity of the userid that started the Link Server task. This raises the question, “what identity should I use to start the Link Server task?”

With a little more work, you can pass the identity of the remote client, or of the client of the remote client. The identity which will be passed to the back end service is under the control of the architects and administrators who set up the configuration. Your configuration will be determined by your security requirements.

The choices listed represent the most likely cases. In the Unit 4 lab we will demonstrate flowing the identity of the remote client to CICS.


Unit 4 - 11


Gaithersburg, MD11

z/OS Connect Security Features: Audit

Lab so far …

● Liberty log files.

“What record is there of security events?”

Liberty Profile

z/OS Connect

CICSCICS

IMSIMS

BatchBatchz/OS

SAF

Remote

Client

Remote

Client

Authentication, Authorization (EJBROLE, CBIND, APPL, TCICSTRN, SURROGAT).

SMF

● SMF type 80.

When an attempt is made to access z/OS Connect resources to which the client has no authority, it's valuable to have an audit trail.

If the Liberty server is configured for Liberty security, the audit trail will be the log files written by the server. (The exception to this is the SERVER and CBIND profiles, which are handled by SAF in all cases.)

If SAF authentication and authorization are used (specified in the server.xml), violations of userid/password, APPL, EJBROLE, SERVER and CBIND will be written as SMF type 80 records (or equivalent) by your SAF subsystem.


Unit 4 - 12

Applying what we've discussed, mobile or PC users will be prompted for their userid and password to ensure security for business applications. Their conversation will be encrypted with SSL to protect their information in transit. The IBM® Security Access Manager (ISAM) for Web provides authentication and proxy services in the DMZ to authenticate the end user to an LDAP database. ISAM has the ability to create an LTPA token (a cookie) which becomes the end-user's credentials as their request is proxied to the Systems of Engagement (SoE). The SoE have a trusted relationship with ISAM based upon client certificate authentication. The SoE provide application and security services to process the end user's request, eventually calling z/OS Connect and (depending on the application) passing the end user's credentials either as an LTPA token or as application data. The trusted relationship between the SoE and z/OS Connect is based on client certificate authentication. Mapping of the end user's LDAP credentials to a SAF identity can be performed by traditional WebSphere. The APAR for doing this on Liberty is PI26630. z.OS Connect can pass the client's SAF identity through WOLA to CICS if necessary, but in the majority of implementations, z/OS Connect will be configured to trust that the SoE is well behaved and will process SoE requests based upon the level of authority granted the SoE by the Authorization Interceptor.


Unit 4 - 13


Gaithersburg, MD13

Unit 2 Lab…

Securing our Lab Implementation

Now that we've discussed the security services generally, let's look at how we've implemented them in the labs so far. In the process of demonstrating how quickly a Liberty profile and z/OS Connect can be configured, we've saved most of the advanced security options for last.

First we'll review the commands you submitted in the topic 2 and 3 labs, then look in detail at what we'll do in the topic 4 lab.


Unit 4 - 14


Gaithersburg, MD14

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

Angel and server…

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

Everyting on z/OS runs under some userid, and we could have run the Liberty server and Angel under USER1, but in a production environment we like to assign a unique SAF userid to each task (or to similar tasks). So we created a RACF group to own the Liberty server and Angel userids, and a group to own the unauthenticated (guest) userid. Then we created LIBANGE for the Angel, LIBSERV for the Liberty server and WSGUEST. These are PROTECTED userids so that no one can logon using their password and misuse them. They have OMVS segments because they use Unix System Services.

Then we created FRED, which is our test userid in SAF. You've been using a userid Fred already, but that Fred was defined in the basicRegistry, defined in the server.xml file. In the Unit 4 lab coming up, you'll switch to RACF as the user registry.


Unit 4 - 15


Gaithersburg, MD15

Liberty Profile Started Tasks The Liberty Profile consists of one or more servers and optionally one Angel.

More Unit 2 …

Angel

The Angel Process runs in an authorized key and provides facilities to Liberty Server Processes to load and access z/OS system services in a way that protects the integrity of the operating system.

Server

Applications like z/OS Connect may need access to z/OS system services like SAF, WLM, dump, and WOLA. Access is not the default.

The Liberty Server is where z/OS Connect runs.

The Angel provides SAF controlled access to z/OS services.

This is an explanation or reminder of the purpose of the Server and Angel tasks. The Server task (address space, proc) provides the Java environment for applications and z/OS Connect to run. As mentioned, Liberty protects against accidental misconfiguration or intentional access to or from the Liberty server. It does this through the Angel process.

Only one Angel process can be running at a time on an LPAR. Attempts to start another will fail. The Angel process provides controlled access to z/OS services for all of the Liberty servers running on the LPAR. If different Liberty servers have different requirements to access z/OS services, then the server tasks should run under different userids. It follows then that the servers should run under different userids than the Angel.

Not all applications or configurations of a Liberty server will require an Angel process, but z/OS Connect uses WOLA, and WOLA requires an Angel process. .


Unit 4 - 16


Gaithersburg, MD16

The RACF Commands from Unit 2 Lab (continued)

● You also assigned the Server and Angel userids to the started procedures.

Unit 3 Lab ...

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

To associate the LIBSERV userid with the Liberty server started task, and the LIBANGE userid with the Angel started task, we defined RACF STARTED profiles.

We ran the script to build the Liberty and Angel servers using the LIBSERV userid because it provided an easy way to get the correct owner and group on the files. After we did that we changed LIBSERV to a PROTECTED userid so no one could use/misuse the LIBSERV password.


Unit 4 - 17


Gaithersburg, MD17

The RACF Commands from Unit 3 Lab

● In Unit 3 Lab you permitted the Liberty Server to use several z/OS authorized services protected by SERVER class profiles.

● USER1.WAS.CNTL(ZCRACF2):

More Unit 3…

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 -


RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.ZOSWLM UACC(NONE)

PERMIT BBG.AUTHMOD.BBGZSAFM.ZOSWLM -



SERVER class SAF rules protect z/OS services from an improperly (or maliciously) configured Liberty server.

BBG.ANGEL grants an ID general access to the Angel process for authorized services.

BBG.AUTHMOD.BBGZSAFM controls which server processes can use the BBGZSAFM authorized module in the Angel process.

BBG.AUTHMOD.BBGZSAFM.SAFCRED controls which server processes can use BBGZSAFM for SAF services.

BBG.AUTHMOD.BBGZSAFM.ZOSWLM controls which server processes can use BBGZSAFM for WLM services.


Unit 4 - 18


Gaithersburg, MD18


● Server class profiles control the use of the Angel, SAF, WLM, RRS, SVC dump, the security prefix and WOLA.

More Unit 3…

RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.TXRRS UACC(NONE)

PERMIT BBG.AUTHMOD.BBGZSAFM.TXRRS -


RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.ZOSDUMP UACC(NONE)

PERMIT BBG.AUTHMOD.BBGZSAFM.ZOSDUMP -


RDEFINE SERVER BBG.SECPFX.BBGZDFLT UACC(NONE)

PERMIT BBG.SECPFX.BBGZDFLT -


RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.WOLA UACC(NONE) OWNER(SYS1)

PERMIT BBG.AUTHMOD.BBGZSAFM.WOLA -



BBG.AUTHMOD.BBGZSAFM.TXRRS controls which server processes can use BBGZSAFM for RRS services.

BBG.AUTHMOD.BBGZSAFM.ZOSDUMP controls which server processes can use BBGZSAFM for z/OS Dump services.

BBG.SECPFX.BBGZDFLT controls access to EJBROLE definitions based on the prefix in use for a server.

BBG.AUTHMOD.BBGZSAFM.WOLA controls which server processes can use BBGZSAFM for WOLA services.


Unit 4 - 19


Gaithersburg, MD19


● An EJBROLE protects z/OS Connect.

More Unit 3 …

RDEFINE SERVER BBG.AUTHMOD.BBGZSAFM.LOCALCOM UACC(NONE) OWNER(SYS1)

PERMIT BBG.AUTHMOD.BBGZSAFM.LOCALCOM -


RDEFINE SERVER BBG.AUTHMOD.BBGZSCFM UACC(NONE) OWNER(SYS1)

PERMIT BBG.AUTHMOD.BBGZSCFM -


RDEFINE SERVER BBG.AUTHMOD.BBGZSCFM.WOLA UACC(NONE) OWNER(SYS1)

PERMIT BBG.AUTHMOD.BBGZSCFM.WOLA -


SETROPTS RACLIST(SERVER) REFRESH

RDEFINE EJBROLE ** OWNER(SYS1) UACC(NONE)

PERMIT ** CLASS(EJBROLE) RESET

SETROPTS RACLIST(EJBROLE) REFRESH


BBG.AUTHMOD.BBGZSAFM.LOCALCOM controls which server processes can use BBGZSAFM for LOCALCOM services.

BBG.AUTHMOD.BBGZSCFM controls which server processes can use the BBGZSCFM authorized module in the Angel process.

BBG.AUTHMOD.BBGZSCFM.WOLA controls which server processes can use BBGZSCFM for WOLA.

EJBROLE rules control which users can invoke applications protected by EJBROLEs. If WebSphere attempts to check an EJBROLE which does not exist, SAF will pass back return code 4, which WebSphere will interpret as a return code 8, meaning the user has no access as the EJBROLE. But since the EJBROLE doesn't exist, there will be no ICH408I message. To help the SAF administrator recognize where EJBROLEs are not defined, a “safety-net” or “backstop” EJBROLE profile should be defined with a UACC of NONE. This rule will match all EJBROLE checks not better defined. A specific EJBROLE to protect z/OS Connect will be defined in Unit 4 lab.


Unit 4 - 20


Gaithersburg, MD20


● A CBIND profile controls which CICS Listener Tasks can register with WOLA. An APPL profile protects z/OS Connect.

Hardening z/OS 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(CICSX)

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

A CBIND class rule controls which CICS listener tasks can register with the WOLA adapter defined by the z/OS Connect server. We'll discuss the CBIND rule and its relationship to the server.xml in more detail on the next slide.

An APPL class rule controls which authenticated users may access the Liberty server. The Liberty server calls SAF to check the authenticated userid for access in an APPL class rule which matches the profilePrefix specified in the safCredentials element of the server.xml. The default value is BBGZDFLT. Since checking an APPL rule and an EJBROLE rule to determine the user's authority is essentially redundant, many implementations set the APPL profile to a UACC of READ and just rely on the EJBROLE, as we have done.


Unit 4 - 21


Gaithersburg, MD21

WebSphere Optimized Local Adapter (WOLA) Security

...

<zosLocalAdapters

wolaGroup="GROUP"

wolaName2="NAME2"

wolaName3="NAME3" />

...

server.xml:

The Liberty Profile defines the WOLA adapter in the server.xml.

The WOLA adapter is protected by a CBIND profile in RACF.

The CBIND profile is based on the WOLA definition.

The Link Server task ID of the CICS partners must be permitted to use the adapter.

The Link Server task ID is the userid which starts the Link Server task.

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

SETROPTS RACLIST(CBIND) REFRESH

Local level …

Liberty Profile

z/OS Connect CICSCICSWOLA

You define the WOLA service to the Liberty server by declaring it with a zosLocalAdapters element in the server.xml file. The zosLocalAdapters element includes the variables wolaGroup, wolaName2 and wolaName3. The value of these variables is used by Liberty as part of the CBIND profile that controls which Link Server tasks may register with the WOLA adapter used by the Liberty server. For this reason, the variables wolaGroup, wolaName2 and wolaName3 should be unique for different WOLA adapters, to protect against the production CICS from accidentally registering with the test z/OS Connect server.

In Unit4 lab we will use USER1 to start the Link Server task, so USER1 must be permitted to the CBIND profile. In your environment you might start the Link Server task under the CICS region's identity or an identity associated with the z/OS Connect server.


Unit 4 - 22


Gaithersburg, MD22

Hardening z/OS Connect with SAF security.

● A SAF keyring/cert for SSL/TLS.

● SAF as the User Registry.

● Enabling Basic or Client Certificate Authentication.

● An EJBROLE to protect z/OS Connect.

● The Authorization Interceptor.

● Passing an Identity to CICS.

SSL …

In Unti 4 lab we will perform the following tasks:

Switch from Liberty's internal SSL configuration to a more representative one using RACF certs and a keyring.

Switch from Liberty's basicRegistry to users in RACF.

Demonstrate RACF authentication using a userid/password first, then switch to client certificate authentication.

Use SAF to check a profile in the EJBROLE class to determine FRED's authority to use z/OS Connect.

Implement the Authorization Interceptor with RACF groups to control what services FRED can perform in z/OS Connect.

Enable CICS transaction security and pass FRED's identity to CICS for authorization checking to the CICS transactions that z/OS Connect calls.


Unit 4 - 23


Gaithersburg, MD23

Using a SAF keyring/cert for SSL/TLSSAF keyrings are under the control of the SAF administrator.

Registry …

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




Liberty Profile

z/OS Connect

CICSCICS

IMSIMS

BatchBatchz/OS

Digital ring information for user LIBSERV:

Ring:

>Keyring.LIBERTY<

Certificate Label Name Cert Owner USAGE

---------------------- -------------------

DefaultCert.LIBERTY ID(LIBSERV) PERSONAL

LibertyCA.LIBERTY CERTAUTH CERTAUTH

The Server (LIBSERV) owns the keyring.

server.xml:

So far in the labs the Liberty server has been using SSL with a self-signed server certificate created when the server was built. In a production environment you would use a SAF server certificate signed by a trusted CA and stored in a SAF keyring.

In Unit 4 lab you will create a SAF keyring (Keyring.LIBERTY) for the LIBSERV userid, a CA certificate and a server certificate for LIBSERV. A RACF listing of the keyring with certs appears in the lower left of the slide. The keyring name will be specified in the server.xml file. Liberty uses Java (JSSE) for SSL support, and SAF keyring names specified to JSSE must have safkeyring:/// followed by the SAF keyring name.

The keyStore directive used previously will be deleted from the server.xml.


Unit 4 - 24


Gaithersburg, MD24

Using SAF as the User Registry

Authentication…

<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" />

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.

The basicRegistry and authorization elements used in Unit 2 and 3 labs will be replaced with the safRegistry and safAuthorization elements, instructing the Liberty server to direct authentication and authorization checks to SAF.

The safCredentials element specifies the userid used to run any server code before authentication takes place, or for those apps where authentication isn't required (public apps). An unauthenticated userid is required, or Liberty won't be able to run apps long enough to authenticate any clients. The default value for unauthenticatedUser is WSGUEST.

The safCredentials element also specifies the SAF profilePrefix, the value of which is prefixed to EJBROLE checks as discussed in later slide. The profilePrefix is also used in the APPL check done by the Liberty server when a user authenticates. The unauthenticatedUser userid is defined as a RESTRICTED userid, which means it must be explicitly permitted to recources by userid or group (no UACC applies). So even if the APPL profile has UACC READ, you must still permit the unauthenticatedUser userid to it.


Unit 4 - 25


Gaithersburg, MD25

Enabling Basic or Client Certificate Authentication

Authorization…

...

<webAppSecurity allowFailOverToBasicAuth="true" />

...

<sslDefault sslRef="DefaultSSLSettings" />

<ssl id="DefaultSSLSettings"

keyStoreRef="CellDefaultKeyStore"

trustStoreRef="CellDefaultTrustStore"

clientAuthenticationSupported="false"

clientAuthentication="false"/>

<keyStore id="CellDefaultKeyStore"




<keyStore id="CellDefaultTrustStore"




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.

ClientClientz/OS

Connect

z/OS

Connect

“Client cert, please.”

“Huh?”

server.xml:

For quick and easy setup and testing of z/OS Connect, basic authentication using a userid and password works well.

The z/OS Connect application expects client certificate authentication, but the server.xml element webAppSecurity allows the server to 'fail-over” to basic authentication if client certificate authentication isn't configured, or if it is configured but the client doesn't have a certificate.

Using a combination of the three variables on the left, you can support three cases:

1. SSL requests are not prompted for a client cert. Only basic authentication is supported. Good for getting started.

2. SSL requests are prompted for a client cert. Client certificate authentication is supported for clients with client certs. Clients without client certs are challenged for a userid and password. Helpful when transitioning your trusted partners to client certs.

3. SSL requests are prompted for a client cert. Requests without a client cert fail the SSL handshake. Requests with a client cert are mapped to a local id, if possible, and treated as authenticated. Best once client certs are deployed.


Unit 4 - 26


Gaithersburg, MD26

An EJBROLE to protect z/OS Connect

<featureManager>

.

.


</featureManager>

...

<authorization-roles id="zos.connect.access.roles">

<security-role name="zosConnectAccess">

<user name="Fred"/>

</security-role>

</authorization-roles>

...





server.xml:

The z/OS 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.zosConnectAccess

To change the profile pattern, see next slide...

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 …

The safAuthorization element causes role checks to be directed to SAF, which checks rules in the EJBROLE class.

The safCredentials element specifies the profilePrefix which is used to build the EJBROLE name that Liberty checks once the client is authenticated, before the application is invoked. The default profilePrefix value is BBGZDFLT.

The resource name used by z/OS Connect is “zos.connect.access.roles”.

The role name used by z/OS Connect is zosConnectAccess.

Put those three pieces together according to the default profile pattern and you get an EJBROLE name of BBGZDFLT.zos.connect.access.roles.zosConnectAccess. That's what the SAF admin defines in the SAF database and is what users will need READ access to in order to access z/OS Connect in this example.

Some have found that EJBROLE name too long. You have some control over the profile pattern. See next slide.


Unit 4 - 27


Gaithersburg, MD27

Controlling the EJBROLE profile pattern

<featureManager>

.

.


</featureManager>

...





<safRoleMapper profilePattern="%profilePrefix%.%role%"

toUpperCase="false" />

server.xml:

The safRoleMapper statement specifies the EJBROLE profile pattern.

The default profile pattern: %profilePrefix%.%resource%.%role%.

The default EJBROLE profile: BBGZDFLT.zos.connect.access.roles.zosConnectAccess

You can control the profile pattern, for example:

RACF commands:

RDEFINE EJBROLE BBGZDFLT.zosConnectAccess OWNER(SYS1) UACC(NONE)

PE BBGZDFLT.zosConnectAccess CLASS(EJBROLE) ID(xxxx) ACCESS(READ)

Front door…

The optional safRoleMapper element in the server.xml file specifies the profile pattern used when Liberty checks EJBROLE names. The default profile pattern %profilePrefix%.%resource%.%role%.

If for example, %resource% is removed from the profilePattern to shorten it up a bit. This is based on the assumption is there's a unique profilePrefix value for each Liberty server, and a Liberty server with a certain profilePrefix only ran z/OS Connect.

Thanks to Kevin Senior of IBM UK for the suggestion.


Unit 4 - 28


Gaithersburg, MD28

The EJBROLE as front door.

● The zosConnectAccess EJBROLE protects the “front door” to z/OS Connect.

● But more access granularity is needed.

RACF commands:

Authorization Interceptor…

zosConnectAccess?

Client

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)

NO

YES

NO Authority

Authority to LIST, START, STOP, INVOKE, get STATISTICS for all RESTful Services.

“All” or “Nothing”

z/OS Connect provides services to authorized users. But some operations are only appropriate for those who administer the services, while others are only appropriate for those who invoke the services. The EJBROLE which protects z/OS Connect makes no distinction between these operations, it's just the “front door” to the application. More granular security is needed.

The z/OS Connect developers created the Authorization Interceptor as a way to provide more granular security to z/OS Connect for those users allowed past the front door. We'll discuss the Authorization Interceptor for a few slides.


Unit 4 - 29


Gaithersburg, MD29

Authorization Interceptor

● Provides three levels of authority for users of your z/OS 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 z/OS Connect global level or for individual services.

Global level …

The z/OS Connect developers see three types of users with respect to services. Those who invoke them, those who operate them and those who administer them. Over time other divisions of authority might be needed, but this seems like a good start.

Rather than use EJBROLEs to represent these three authorities, the developers check the caller's membership in groups which represent of each type of user. You choose the group names, define them in SAF, and specify them to z/OS Connect in the server.xml.

When a request comes in to z/OS Connect, it checks if the user is a member of a group which permits the requested access. If so, the request is process. If not, the request is denied with a status code 403, forbidden. Since no resource rule is checked (just group membership), there is no ICH408I message, but a message appears in the Liberty log file.

If you only have one service in z/OS Connect, or multiple services using a common set of groups, define the groups at the global level for that z/OS Connect. If your z/OS Connect supports multiple different services, you can define groups for the services at the service level. The service level groups override the global ones.


Unit 4 - 30


Gaithersburg, MD30

Implementing the Authorization Interceptor

...

<zosConnectManager

globalAdminGroup="GADMIN"

globalOperationsGroup="GOPERS"

globalInvokeGroup="GINVOKE"

globalInterceptorsRef="interceptorList_g" />

<authorizationInterceptor id="auth" />

<zosConnectInterceptors

id="interceptorList_g"

interceptorRef="auth,audit"/>

server.xml:

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.

RACF commands:

ADDGROUP GADMIN OMVS(AUTOGID)

ADDGROUP GOPERS OMVS(AUTOGID)

ADDGROUP GINVOKE OMVS(AUTOGID)

CONNECT USER1 GROUP(GADMIN)

CONNECT FRED GROUP(GINVOKE)

Service level …

At the global level:

Groups are defined at the global level in the zosConnectManager element of the server.xml. The value that you assign to variable globalAdminGroup becomes the group that z/OS Connect checks for membership to determine if a user has administrative authority. The value that you assign to variable globalOperationsGroup becomes the group that z/OS Connect checks for membership to determine if a user has operations authority. The value that you assign to variable globalInvokeGroup becomes the group that z/OS Connect checks for membership to determine if a user has invoke authority.

You define the groups in RACF using the ADDGROUP command. You include a user in the group using the CONNECT command. To remove a user from a group you use the REMOVE command.

The global group definitions apply to all services in the z/OS connect server. If you have multiple services and you want to use different groups for each, you can define additional groups at the service level.


Unit 4 - 31


Gaithersburg, MD31

Implementing the Authorization Interceptor

...

<zosConnectService id="CICS"

invokeURI="/myCICSBackend"

serviceName="CICS-backend"

dataXformRef="xformJSON2Byte"

serviceRef="wolaCICS"

adminGroup="SADMIN"

operationsGroup="SOPERS"

invokeGroup="SINVOKE" />

server.xml:

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.

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…

At the service level:

Service level takes precedence over Global.

Groups are defined at the service level in the zosConnectService element of the server.xml. The admin group name is specified by adminGroup, the operations group by operationsGroup and the invoke group by invokeGroup. Groups defined at the service level apply only to the zosConnectService they are associated with.

The groups are defined in RACF the same as the global groups are, and the same commands are used to manage them.

If you don't define groups at the global or service level, a user with the zosConnectAccess role has full authority to all services. If you define groups at the global level, but none at the service level, the global groups apply to the service(s). If you define groups at the service level, they override the groups you defined at the global level.


Unit 4 - 32


Gaithersburg, MD32

Passing the Client's Identity to CICS

Propagation Checklist…

Starting the Link Server task (BBOC):

z/OS

...

SEC=Y

XTRAN=YES

XUSER=YES

...

CICS SIP:

Liberty Profile

z/OS Connect CICSCICSWOLA

server.xml:

...

<zosLocalAdapters

useCicsTaskUserId="true"

wolaGroup="GROUP"

wolaName2="NAME2"

wolaName3="NAME3" />

...

BBOC START_TRUE

BBOC START_SRVR RGN=CICSREG DGN=GROUP NDN=NAME2 SVN=NAME3 SVC=* MNC=1 MXC=10 TXN=N

SEC=Y REU=N TRC=1

Passes the SAF identity of the

z/OS Connect client to CICS.

CICS security enabled.

Transactions protected.

Link Server's userid checked for surrogate authority to the passed userid.

CICS uses the passed userid instead of the Link Server task userid.

We've discussed how the zosLocalAdapters element defines the WOLA adapter in the Liberty server. There's an optional property in the zosLocalAdapters element which determines whether WOLA will pass the SAF identity of the z/OS Connect client to CICS. The default is false, but if you set it to true, that's one step towards CICS checking the identity of the z/OS Connect client.

Another factor is how you start the CICS Link Server task. The SEC parameter of the BBOC START SRVR command determines whether CICS will use the WOLA passed userid versus running the request under the Link Server task. If SEC=Y, the passed userid is used. If SEC=N (the default) the Link Server task is used.

This assumes that CICS security is enabled in CICS, specified in the CICS system initialization parameters (SIP or SIT). If SEC=Y in the SIP, CICS security is on, along with XTRAN=YES, which means CICS transactions cannot be invoked without the client being authenticated. Since the client identity is passed by WOLA without a password, XUSER=YES causes CICS to check if the Link Server task has the authority to “assert” the individual userids. This requires that the Link Server task userid has permission in rules in the SURROGAT class.

This slide shows the settings that cause the user's identity to be passed and used. The next slide shows the permissions required by the various parties.


Unit 4 - 33


Gaithersburg, MD33

RACF Checklist for Passing an Identity to CICS

● The Link Server ID needs:

● READ access to the CBIND profile: BBG.WOLA.GROUP.NAME2.NAME3

● READ access to TCICSTRN profiles BBOC and BBO$ (Link server task)

● READ access to SURROGAT profile <passedid>.DFHSTART

● The identity being flowed/asserted needs:

● READ access to TCICSTRN profile BBO# (Link invocation task)

● READ access to EJBROLE profile: BBGZDFLT.zos.connect.access.roles.zosConnectAccess

Time for Unit 4 Lab…

Once you have z/OS Connect working with WOLA and passing requests to CICS, you may decide you want z/OS Connect to pass the remote client's SAF identity. After completing the changes on the previous slide, CICS will be checking the passed userid's authority to the transactions involved.

Here's a checklist of the SAF permissions needed for our lab.

The Link Server id needs authority to register with WOLA (it needs this whether an id is passed or not).

The Link Server id needs permission to invoke the BBOC and BBO$ transactions, part of the Link Server task.

The Link Server id needs authority to assert the passed userids (since no password for them is passed). These rules are in the SURROGAT class.

The userid passed and asserted by z/OS Connect authority to invoke transaction BBO# (part of the Link Server task.

And of course the userid being passed will have had authority to use z/OS Connect to begin with.

End of UnitEnd of Unit

Documents

Unit 4 - zOS Connect Security...Unit 4 – z/OS Connect Security Unit 4 - 4 © 2014 IBM Corporation IBM Americas Advanced Technical Skills Gaithersburg, MD 4 z/OS Connect Security