GSE- WebSphere MQ zOS Security

IBM Software Group

© 2004 IBM Corporation

WebSphere MQ for z/OS SecurityHazel [email protected]


GSE UK Enterprise Security Working GroupApril 20th 2005

© IBM Corporation 2004

Transaction & MessagingTechnical Conference

Abstract

This presentation will provide an introduction to WebSphere MQ for z/OS Security, looking at, what security is available, how it is activated/deactivated, what types of resources can be protected and an insight as to how WebSphere MQ for z/OS determines which userids it uses for the checks it performs.

1-2 21/04/05



Agenda

Security Overview

Controlling Security for WebSphere MQ for z/OS

Access Control

Administration

Summary



Security Overview

3-4 21/04/05



What are we trying to achieve?

Identification:- Being able to Identify uniquely a user of a system or an application that is running in the system.

Authentication:- Being able to prove that a user or application is genuinely who that person or what that application claims to be.

Access Control:- Protects critical resources in a system by limiting access only to authorised users and their applications. It prevents unauthorised use of a resource or the use of a resource in an unauthorised manner.

Auditing:- Tracking who has done what to what and when.

Security Overview



Confidentiality:- Protects sensitive information from unauthorised disclosure.

Data Integrity:- Detects whether there has been unauthorised modification of data. There are two ways in which this can occur, accidentally, through hardware or transmission errors, or by deliberate attack.

'Non-Repudiation':- The goal is usually to prove that a particular message is associated with a particular individual.

Security Overview

5-6 21/04/05



CICS IMS CICSIMSz/OS z/OS

BatchAPPL

BatchAPPL

IMSAPPL

CICSAPPL

CICSAPPL

IMSAPPL

Queue Manager A

Queue Manager B

MOVER

MOVER

A1 A2

B2

B1

links to other MQ systems

WebSphere MQ for z/OS (non Queue Sharing groups)



N

O

T

E

S

Overview - NotesThis presentation provides an overview of the way that security is implemented for the WebSphere MQ environment on z/OS. It is assumed that the audience is already familiar with WebSphere MQ concepts, with the z/OS environment and with security in general. Thus, the intent is to provide a description of the way that security facilities are provided for this particular environment. There is a description of what the security environment is, how it is activated and how access control is done.

Although security services are provided generically on z/OS via the SAF interface, there is an emphasis in these charts to RACF. All of the concepts will be easily extendible to other security manager products.

Throughout the presentation 'hlq' is used as a prefix for profile names. This can be either 'subsystem id' ,the name of the Queue Manager to which the profile is relevant, or 'queue sharing group id' the name of the queue sharing group to which the qmgrs belong..

Prior to v5.2 profiles could not be shared across qmgrs due to the way the profiles were stored and accessed.

In v5.2 Queue sharing group support was added, the way the way the profiles are stored was changed, so if you are using this facility you can now share profiles across Queue managers within a Queue Sharing group by using the appropriate high level qualifier .

7-8 21/04/05



mover

mover

mover

SQM1

SQM2

SQM3

localpagesets

localpagesets

locallogs

locallogs

locallogs

localpagesets

QSGIMS

CICS

BATCH

locallogs

mover

LQM1

localpagesets

z/OS

DB2

MQCF

SQ1

MQ

WebSphere MQ for z/OS Queue Sharing Groups



Security Overview

WebSphere MQ

External Security Manager

WebSphere MQ

PROFILES

WebSphere MQ

PROFILES

SAF

SAF to provide choice of External Security Manager RACF, ACF2, Top Secret, ...WebSphere MQ has a set of classes to hold profilesProfiles provide access control capabilities

Features depend upon profiles usedz/OS control is more granular than other systems

Activate classes, and allow generic profilesSETROPTS CLASSACT(...)SETROPTS GENERIC(...)

ClassesMQADMINMQCONNMQCMDSMQQUEUEMQPROCMQNLIST

9-10 21/04/05



N

O

T

E

S

Security Overview WebSphere MQ for z/OS uses the z/OS System Authorisation Facility (SAF) to provide access control services within the z/OS environment. This is the standard mechanism of providing security in an z/OS environment and has two significant advantages; firstly, there is a security manager for the entire z/OS environment and secondly there is a choice of External (to WebSphere MQ) Security Manager (ESM) to choose from, providing greater flexibility.

Access Control Lists (ACLs) are implemented as a set of profiles. A user is granted access to a particular profile to allow access to the protected resource. To contain the profiles, WebSphere MQ 'defines' a set of classes, as follows:

MQADMIN contains profiles for administration functions,command resources, context and alternate userid checking

MQCONN contains profiles to limit connection to the MQ subsystem

MQCMDS contains profiles for command security

MQQUEUE controls queue resources

MQPROC controls process resources

MQNLIST controls namelist resources

These lists are defined to the RACF system and need to be defined to other security manager products as well.

11-12 21/04/05






Controlling Security

High Level Qualifiers

Shared Queue Manager Environment

Security Switches Switch profiles Options available under Queue Sharing

Groups

Queue Sharing Group rules

13-14 21/04/05



Controlling Security - High Level Qualifiers

Queue Manager qualified profiles

Queue Manager profiles use the queue manager name as the high level qualifier for example:- qmgr.profile.name and their scope is limited to the named Qmgr.

Queue Sharing Group qualified profiles

Queue sharing group profiles will use the queue sharing group id as their high level qualifier instead of a queue manager name for example: - qsg.profile.name and their scope is the named Queue Sharing Group.

15-16 21/04/05



DB2 Setting up Resources in DB2Connection to DB2Access to DB2 resourcesCoupling FacilitySetting up the Coupling FacilityAccess to the Coupling Facility Queue Sharing Groups (QSG)Setting up QSG'sJoining a QSG

Controlling Security - Shared Queue Manager Environment



N

O

T

E

S

IBM Corporation 2001

Controlling Security - Shared Queue Environment - notes

DB2

Shared Queue Managers connecting to DB2 will have connection checking performed by DB2. Use existing security facilities in DB2 to set this up. The Shared Queue managers address space Userid will be used for this connection check.

Coupling Facility (CF)

In order for a Shared Queue Manager to have access to structures in the CF, each Queue Manager address space's Userid must have ALTER access to the relevant RESOURCE(IXLSTR.structure_name) profiles in the CLASS(FACILITY).

Queue Sharing Groups (QSG)

At Shared Queue Manager start up the Qmgr will attempt to connect to a XCF group for the Queue Sharing Group. The IXCCREAT to the group is subject to security checks, and these will ensure that the Shared Qmgr is allowed to join the group.

Use existing security facilities in these areas

17-18 21/04/05



Controlling Security - Switch Profiles

Granular control of security checking

Subsystem security hlq.NO.SUBSYS.SECURITY

Qmgr or QSG Securityhlq.NO.QMGR.CHECKS hlq.NO.QSG.CHECKS

In QSG also have 'YES' switch profiles

ssid.YES.typeThese profiles are only used if you have chosen to have both Qmgr and QSG checking active and need to override a Qsg level profile on a given Qmgr. The hlq on these profiles is always 'ssid' - in other words the qmgr ID

** You cannot set both QMGR & QSG to OFF together - if you try this you will get both Qmgr and Qsg security activated **



N

O

T

E

S

Controlling Security - Switch Profiles - Notes Switch profiles are RACF profiles which control the level of security checking carried out by WebSphere MQ. These profiles are not used in the same way that profiles are normally used - for access control. They are used simply as switches to activate/deactivate access control checking for various components of Queue Manager processing. Thus, userids are not permitted various access rights to these profiles.

The default action for WebSphere MQ is to have access control checks activated. The presence of a switch profile will deactivate security checking for the appropriate component. As these switch profiles are not present by default, it means that explicit action is required to deactivate security processing within an WebSphere MQ environment, once RACF is active and the WebSphere MQ classes are defined (as no checking is possible otherwise !).

If the hlq.NO.SUBSYS.SECURITY profile is present then no further checks are made for other switch profiles.

Activating security support in this way means that no security system management is done from within the Queue Manager, which is deemed to be a good thing. However, the use of profiles in this way is quite unusual.

Qmgr and QSG Switches

- QMGR checks switch - controlled by the profile hlq.NO.QMGR.CHECKS used to determine whether or not security checks can use profiles with a hlq of 'ssid'

- QSG checks switch - controlled by the profile hlq.NO.QSG.CHECKS used to determine whether or not security checks can use profiles with a hlq of 'qsg'

** You cannot set both QMGR & QSG to OFF together - if you try this you will get both Qmgr and Qsg security activated.

The default is for both to be active and for ssid qualified profiles to be looked for first.

However - this means that you can be in a situation where for example a profile: QSG1.NO.CMD.CHECKS turned OFF Command security on all Qmgrs within the Queue sharing group, but one Qmgr (e.g.: QMD) wants command security ON

So for every hlq.NO profile there is now an equivalent ssid.YES profile which will override a qsg.NO profile for a given subsystem if set up correctly.(covered later)

19-20 21/04/05



Controlling Security - Switch Profiles

all defined in MQADMIN class

Connection Securityhlq.NO.CONNECT.CHECKS

MQ Command Securityhlq.NO.CMD.CHECKShlq.NO.CMD.RESC.CHECKS

MQ API Securityhlq.NO.QUEUE.CHECKShlq.NO.PROCESS.CHECKShlq.NO.NLIST.CHECKShlq.NO.CONTEXT.CHECKShlq.NO.ALTERNATE.USER.CHECKS



N

O

T

E

S

Controlling Security - Switch Profiles- Notes The different switches represent the different components of WebSphere MQ to which access control checks may be applied and are split into the following areas:

Connecting to the Queue Manager

MQ API - Covering, Queues, Processes, Namelists, Context information and Alternate Userids.

MQ commands and their associated resources

Command security and Command Resource security checking were originally designed to be used together to provide a greater granularity to determine whether the issuer of the command was allowed to do so and also, if that command affected a resource, whether they were allowed to issue that particular command for the given resource. If they are both active, then all commands issued that affect resources will have both security checks carried out and must pass both checks for the command to be issued.

However each one can be used independently. If you just have Command security active, the only check performed is to determine whether the issuer of the command is authorised to do so. If authority is granted the command will be issued.

If you just have Command Resource security active then anyone can issue commands that do not affect resources, but if a resource is affected a Command Resource security check will be performed to determine whether the issuer is allowed to issue that command for the named resource.

If the MQADMIN class is not present or not activated (or there is no external security manager) - security checking is deactivated.

Generic switch profiles such as hlq.NO.** are not detected by WebSphere MQ

21-22 21/04/05



Controlling Security - Security Switch options

QMGR

Local QMGR?

SharedQMGR?

Qmgr only

QMGRonly?

QSGonly?

QMGR& QSG?

Not QSGssid only

Queue Sharing GroupUp to three profiles looked forwhen checking for:

Subsystem securityQueue Manager securityQSG security



N

O

T

E

S

Controlling Security - Security Switch options - Notes

If you are not in a Queue sharing group then only switch profiles with a hlq of 'ssid' are looked for ,where 'ssid' is the Qmgr ID of the qmgr you are running.

However if you are in a Queue sharing group then for the first three switches, the Subsystem security, Qmgr checking and QSG checking switches, it is possible that up to three profiles are looked for, for each switch to determine which of these switches is activated and what level of security checking will take place from that point onwards.

The following foils show the order in which the first three switches are checked and the hierarchy of profiles that are checked

23-24 21/04/05



Shared Queue Environment

Qmgr

local shared

ssid.NO.SUBSYS.SECURITY

qsg.NO.SUBSYS.SECURITY

ssid.YES.SUBSYS.SECURITY

qmgr qmgr

not found

not found

found

found

set Subsys security OFF on this qmgr

found not found

ssid.NO.SUBSYS.SECURITY

found not found Set Subsys security OFF on this qmgr

set Subsys security ON on this qmgr

set Subsys security OFF on this qmgr

set subsys security ON on this qmgr

set Subsys security ONon this qmgr

Controlling Security - Security Switch options - continued...

1

2

3



N

O

T

E

S


subsys

ssid.NO.QMGR.CHECKS

qsg.NO.QMGR.CHECKS

ssid.YES.QMGR.CHECKS

not found

not found

found

found

set QMGR security OFF on this qmgr

found not foundset QMGR security OFF on this qmgr

set QMGR security ON on this qmgr

set QMGR security ON on this qmgr

ON

Controlling Security - Security Switch options

4

5

6

25-26 21/04/05



N

O

T

E

S

subsys

ssid.NO.QSG.CHECKS

qsg.NO.QSG.CHECKS

ssid.YES.QSG.CHECKS

not found

not found

found

found

set QSG security OFF on this qmgr

found not found set QSG security OFF on this qmgr

set QSG security ON on this qmgr

set QSG security ON on this qmgr

ON

Controlling Security - Switch Options


7

8

9



N

O

T

E

S

Controlling Security - Switch options Once the SUBSYSTEM, QMGR and QSG switches have been set up we can then use the results of those

checks to determine how much checking needs to be done for the remainder of the switches.

If both QMGR and QSG switches are active then we follow the process shown on the previous foils to

determine how to set the remaining switches.

If either QMGR only or QSG only checking is active the we only look for the switch profile with the relevant

high level qualifier.

For example, if QSG only checks are active, for the remainder of the switches we will look for

qsg.NO.'type'.checks profiles, where 'type' is substituted with the relevant security switch type.

27-28 21/04/05



Rulesdefault is check ssid profiles before qsg profiles

ssid.YES switch profiles override qsg.NO switch profiles QMGR checks switch ON / QSG checks switch OFF means ONLY profiles with a hlq of ssid will be usedQSG checks switch ON / QMGR checks switch OFF means ONLY profiles with hlq of qsg will be used

You cannot set security OFF by setting both QMGR & QSG checking

OFF together - it will default both ON

Once the QMGR and QSG switches have been determined then the remaining switch profiles are checked following the QMGR/QSG rulesOnce the Shared Queue Manager is up and running all security checks are governed by the setting of the individual switch for that type of security and the QMGR/QSG switch stateIf both QMGR and QSG switches are ON then a hlq of ssid will be used first and if not found then a hlq a qsg will be used on the security check

Controlling Security - Queue Sharing Groups



N

O

T

E

S

Controlling Security - Queue Sharing Groups rules

Rules

- default is check ssid profiles before qsg profiles

- ssid.YES profiles override qsg.NO profiles

- QMGR checks switch ON / QSG checks switch OFF means ONLY profiles with a hlq of ssid will be used

- QSG checks switch ON / QMGR checks switch OFF means ONLY profiles with hlq of qsg will be used

- Both QMGR and QSG switches ON then and hlq of ssid will be used first and if not found then a hlq

of qsg will be used on the security check.

- Once the QMGR and QSG switches have been determined then the remaining switch profiles are checked following the local/shared rules.

- Once the Shared Queue Manager is up and running all security checks are governed by the setting of the

individual switch for that type of security and the QMGR/QSG switch state

29-30 21/04/05



N

O

T

E

S

Example1 of the use of Switch Profiles

Three WebSphere MQ subsystems have been defined called PROD,DEVT,and TEST (not in a QSG).

All the RACF classes have been defined and activated.

The three systems have different requirements:

PROD system wants full security

DEVT only wants Connection and Queue security active

TEST doesn't want any security at all.

So how do these requirements relate to switch profiles ?

PROD - wants full security.

For this you need to ensure that there are no

PROD.NO switch profiles defined in the MQADMIN class

You can check this using the RACF SEARCH command

SEARCH CLASS(MQADMIN) MASK(PROD.NO) LIST

and by checking the output.



N

O

T

E

S

Example1 - Switch profiles

DEVT - requires Connection and Queue security only

This can be done by defining DEVT.NO switch profiles for each of the security types you DO NOT want.

RDEFINE MQADMIN DEVT.NO.CMD.CHECKS

RDEFINE MQADMIN DEVT.NO.CMD.RESC.CHECKS

RDEFINE MQADMIN DEVT.NO.PROCESS.CHECKS

RDEFINE MQADMIN DEVT.NO.NLIST.CHECKS

RDEFINE MQADMIN DEVT.NO.CONTEXT.CHECKS

RDEFINE MQADMIN DEVT.NO.ALTERNATE.USER.CHECKS

You should also ensure there are no other DEVT.NO switch profiles in the MQADMIN class by using the SEARCH command as shown for PROD and checking that only the ones you want are defined

TEST - requires no security at all

This is done by defining the NO.SUBSYS.SECURITY switch profile in the MQADMIN class.

RDEFINE MQADMIN TEST.NO.SUBSYS.SECURITY

This turns off security checking for that entire subsystem until such a time the switch is reset.

31-32 21/04/05



N

O

T

E

S

Example 2 of the use of Switch ProfilesThree WebSphere MQ subsystems have been defined called PRO1, PRO2 and PRO3 ( in a QSG called PROD).


The three systems have the same requirements:

PRO1, PRO2 and PRO3 want full security at QSG level




N

O

T

E

S

Example2 - Switch profiles PRO1, PRO2 and PRO3 - want full security at QSG level.

For this you need to ensure that there are no PRO1.NO , PRO2.NO or PRO3.NO or PRO1.YES, PRO2.YES or PRO3.YES switch profiles defined in the MQADMIN class

You can check this using the RACF SEARCH commands

SEARCH CLASS(MQADMIN) MASK(PRO1.NO) LIST



SEARCH CLASS(MQADMIN) MASK(PRO1.YES) LIST




You then need to define a QSG level profile to turn

OFF QMGR checking in the QSG, use the following RACF command to do this

RDEFINE MQADMIN PROD.NO.QMGR.CHECKS

33-34 21/04/05



N

O

T

E

S

Example3 of the use of Switch ProfilesThree WebSphere MQ subsystems have been defined called PROD, DEVT and TEST ( in a QSG called PDT1 ).


The three systems have different requirements:

PROD system wants full security at QSG level

DEVT only wants Connection and Queue security active

TEST doesn't want any security at all.


note: this an unrealistic scenario as Devt and Test will have open access to shared resources on the production system, which is not a good idea, but it serves as a useful example of mixed profiles

PROD - wants full security at QSG level.

You need to ensure that there are no PROD.NO or PROD.YES switch profiles defined in the MQADMIN class, You can check this using the RACF SEARCH commands

SEARCH CLASS(MQADMIN) MASK(PROD.NO) LIST

SEARCH CLASS(MQADMIN) MASK(PROD.YES) LIST


You then need to define a QSG profile to turn off Qmgr checking using the RACF command

RDEFINE MQADMIN PDT1.NO.QMGR.CHECKS



N

O

T

E

S

Example3 - Switch profiles DEVT - requires Connection and Queue security only

You need to turn on QMGR checking for DEVT, use the following RACF command to do this

RDEFINE MQADMIN DEVT.YES.QMGR.CHECKS

this will override the QSG one to turn it off.

Then define the following DEVT.NO switch profiles for

each of the security types you DO NOT want.

RDEFINE MQADMIN DEVT.NO.CMD.CHECKS

RDEFINE MQADMIN DEVT.NO.CMD.RESC.CHECKS

RDEFINE MQADMIN DEVT.NO.PROCESS.CHECKS

RDEFINE MQADMIN DEVT.NO.NLIST.CHECKS

RDEFINE MQADMIN DEVT.NO.CONTEXT.CHECKS

RDEFINE MQADMIN DEVT.NO.ALTERNATE.USER.CHECKS

TEST - requires no security at all

This is done by defining the NO.SUBSYS.SECURITY switch profile in the MQADMIN class.

RDEFINE MQADMIN TEST.NO.SUBSYS.SECURITY

This turns off security checking for that entire subsystem until such a time the switch is reset.

35-36 21/04/05



Access Control



Access Control

Connection Security

Reslevel Security

API securitycovering profiles and userids checkedLink Level Security

37-38 21/04/05



Connection SecurityREAD access required by adapter userid

Access Control

Profiles are held in the MQCONN classOne profile per adapter typehlq.BATCHhlq.CICShlq.IMShlq.CHIN

Connection type Userid used

Batch The TSO UseridThe Userid assigned to the batch job via the USER JCL parm The Userid assigned to the started task by the STARTED class or the started procedures table

CICS The CICS address space Userid

IMS The IMS region Userid

Channel Initiator The Channel Initiator address space Userid



N

O

T

E

S

Access Control - Connection security - Notes Qmgr hlq's

If you have a 'hlq' of a qmgr name then the profile controls access to the related qmgr, for that

connection type

Qsg hlq's

If you have a 'hlq' of a qsg name then the profile controls access to all qmgrs within the QSG for that

connection type.

The userid used for connection checking is the userid associated with the address space performing

the connect, for example

TSO Userid or TSO job Userid

CICS address space Userid

IMS address space Userid

CHINIT address space Userid

39-40 21/04/05



Access Control - RESLEVEL Profile

Single profile per Queue Manager or Queue Sharing Group in the MQADMIN class and looks like

hlq.RESLEVEL

Controls the number of userids used for access control on MQ API Resource Security

Executing userids access to RESLEVEL profile determines the number of userids - last for the life of that connection



N

O

T

E

S

Access Control - RESLEVEL Profile - Notes While the switch profiles control what checks are made by WebSphere MQ, the RESLEVEL profile controls which userid - or userids - will be checked. The number of userids for which checks will be carried out depends on two factors:

The access that the adapter userid has to the hlq.RESLEVEL profile. The adapter userid is the userid of the address space in which the adapter is running.

The environment in which the adapter is running ... batch/TSO, CICS , IMS, Mover or Intra-group queuing. The number of userids checked will be 0, 1 or 2, though for the batch/TSO adapter it will be 0 or 1. The higher the level of access that the adapter userid has to the hlq.RESLEVEL profile, the fewer checks will be made.

As there is just one Reslevel profile per Queue Manager or Queue Sharing group, ensure that if you use the same userid in different environments, that you have set the access level for that userid to hlq.RESLEVEL correctly so that you get the highest level of checking required out of those environments. You will not be able to set it differently for each environment that uses the same userid.

41-42 21/04/05



N

O

T

E

S

Access Control - RESLEVEL Profile - Notes NOTE !

Reslevel with both QMGR and QSG checking active

Before Queue Sharing Groups existed, if you did not have a ssid.RESLEVEL profile then the default would be to set the number of userids to be checked to TWO userids.

However Reslevel profile checks behave slightly differently to today but ONLY when both QMGR and QSG security checks are active.

In this instance you can no longer rely on not having a ssid.RESLEVEL profile defined to force two userid checking for that system There could be a qsg.RESLEVEL profile defined that causes a different level of checking to be active.

If on a given QMGR you want to ensure two userid checking is active then you should define the ssid.RESLEVEL profile and grant the relevant userids access = NONE .



N

O

T

E

S

Reslevel and Batch

If there is no RESLEVEL profile and you are NOT running with both Qmgr and QSG checking active then WebSphere MQ enables checking for two user IDs. If there is a RESLEVEL profile, the level of checking depends on the access level granted to the Job Userid or TSO Userid. The table below shows the checks made for Batch/TSO adapter

Access Control - Reslevel and Batch - Notes

RACF access level Level of checking

NONE Check job/TSO(or alternate) userid

READ Check job/TSO(or alternate) userid

UPDATE Check job/TSO(or alternate) userid

CONTROL No check

ALTER No check

The Ops and Control panels and CSQUTIL Utility are Batch applications - you can use RESLEVEL to bypass security checking for the SYSTEM.COMMAND.INPUT and SYSTEM.COMMAND.REPLY.MODEL queues they use but NOT the dynamic queues SYSTEM.CSQOREXX.* and SYSTEM.CSQUTIL.*

43-44 21/04/05



N

O

T

E

S

Reslevel and CICS

If there is no RESLEVEL profile and you are NOT running with both Qmgr and QSG checking active then WebSphere MQ enables checking for two user IDs. If there is a RESLEVEL profile, the level of checking depends on the access level granted to the CICS address space userid. The table below shows the number of userids checked for CICS adapter

Access Control - Reslevel and CICS - Notes


NONE Check the CICS address space and the task or Alternate Userid

READ Check the CICS address space userid

UPDATE Check the CICS address space userid and if the transaction has been defined with RESSEC=YES also check the task or alternate userid

CONTROL No Check

ALTER No CheckIf the transaction is defined to CICS with RESSEC(NO), check the CICS address space userid only.The status of CICS security is NOT checked, when taking into consideration the transaction RESSECsetting. For example if CICS has been started with RESSEC(NO) but the transaction has beendefined with RESSEC(YES), MQ will still check both userids.

Note: If you set up your CICS address space Userid with the 'trusted' attribute in the STARTED class or the RACF started procedures table ICHRIN03, this overrides any Userid checks for the CICS address space established by the RESLEVEL profile for your Qmgr. That is the Qmgr does NOT perform the security checks for that CICS address space.



N

O

T

E

S

Reslevel and IMS

If there is no RESLEVEL profile and you are NOT running with both Qmgr and QSG checking active then WebSphere MQ enables checking for two user IDs. If there is a RESLEVEL profile, the level of checking depends on the access level granted to the IMS address space userid. The table below shows the number of userids checked for IMS adapter

Access Control - Reslevel and IMS - Notes


NONE Check the IMS address space and the IMS second Userid or Alternate Userid

READ Check the IMS address space userid

UPDATE Check the IMS address space userid

CONTROL No Check

ALTER No Check

When IMS transactions connect to WebSphere MQ, there are (as with CICS on OS/390) two userids used for controlling access to WebSphere MQ resources. These are:1. The address space userid - for either the IMS Control region or IMS Dependent region2. One of - userid associated with the IMS transaction - LTERM name - PSBNAME The choice of which of these to use is driven by the type of dependent region, according to the following table

45-46 21/04/05



N

O

T

E

S

Access Control - RESLEVEL and IMS - Notes

1.BMP message driven and successful GET UNIQUE issued2.IFP and GET UNIQUE issued3.MPP

1.BMP message driven and successful GET UNIQUE not issued2.BMP not message driven3.IFP and GETUNIQUE not issued

1.Userid associated with the IMS transaction if the user id signed onor2.LTERM name if availableor3.PSBNAME

1.Userid associated with the IMS dependent region address space if this is not blanks/zeroesor2.PSBNAME

Type of dependent region Hierarchy for determining 2nd userid

IMS second userid determination



N

O

T

E

S

Reslevel and Channel Initiator Connections

If there is no RESLEVEL profile and you are NOT running with both Qmgr and QSG checking active then WebSphere MQ enables checking for two user IDs. If there is a RESLEVEL profile, the level of checking depends on the access level granted to the Chinit address space userid, the communications protocol you are using and the Channel definitions . The table below shows the number of userids checked for Channel Initiator connections. The Userids checked can be a combination of the following, the MCAUSER on the channel definition, the Userid received from the network, the SSL derived Userid, the Channel initiator Userid or the alternate Userid from the MQMD. Which Userids are used when is covered later.

Access control - Reslevel and Mover Connections - Notes


NONE Check two userids

READ Check one userid

UPDATE Check one userid

CONTROL No Check

ALTER No Check

47-48 21/04/05



N

O

T

E

S

Reslevel and IGQ

The Intra-Group queuing agent does not issue an explicit connect request as it is an internal queue

manager task and runs under the user ID of the queue manager. This means that the processing for this

is slightly different to the existing Reslevel processing.

The intra-group queuing agent starts at queue manager initialisation. During the initialisation of the

intra-group queuing agent, WebSphere MQ checks the access the user ID associated with the queue

manager has to a profile called:

hlq.RESLEVEL

This check is always performed when subsystem security is active.

Access Control - Reslevel and IGQ - Notes



N

O

T

E

S

Reslevel and IGQ continued.

If there is no RESLEVEL profile, WebSphere MQ enables checking for two user IDs. If there is a RESLEVEL profile, the level of checking depends on the access level granted to the user ID of the queue manager for the profile. The userids checked can be a combination of the following, the Userid determined by the IGQUSER attribute of the receiving Qmgr, the Userid of the Qmgr within the QSG that put the message on the SYSTEM.QSG.TRANSMIT.QUEUE, or the Alternate Userid from the MQMD.

The table below shows the checks made for the intra-group queuing agent.

Access control - Reslevel and IGQ - Notes continued

If the access granted to the RESLEVEL profile for the queue manager's user ID are changed, the intra-group queuing agent must be stopped and restarted to pick up the new access level.Because there is no way to independently stop and restart the intra-group queuing agent, the queue manager must be stopped and restarted to achieve this.

It is important to think about this setting carefully and get it right initially.





CONTROL No Check

ALTER No Check

49-50 21/04/05



Access Control - MQ API Security

Access to Resources

This can be controlled by more than one profile and can involve several security checks depending on the set up.

Profiles used for Resource security checking are held in the following classes

MQPROC - ProcessesMQNLIST - NamelistsMQQUEUE - QueuesMQADMIN - Context and Alternate Userids



Access control - MQ API Security

Processes and Namelists Security - are opened for inquiry onlyMQPROC class - profiles look like

hlq.processname

READ access required by userid(s)

MQNLIST class - profiles look like

hlq.namelistname

READ access required by userid(s)

51-52 21/04/05




Queue Security Profiles are held in the MQQUEUE class and look like

hlq.resourcename

A profile can protect a single Local queue on a local Qmgrseveral Local queues of the same name on different Shared qmgrs in a QSGa single Shared queue in a QSGa remote qmgr for fully qualified Remote Queues



N

O

T

E

S

Access Control - High Level Qualifiers - notesQueue Manager profiles

- Queue Manager profiles use the queue manager name as the hlq.

for example:- qmgr.resourcename

Queue Sharing Group profiles

- Queue sharing group profiles will use the queue sharing group id as the hlq instead of a queue manager name

for example: - qsg.resourcename

So, one queue sharing group profile could be used

- to control access to a single shared queue from any user on any shared queue manager within the queue sharing group for example: - qsg.SHARED.QUEUE.ALL protects a shared queue called SHARED.QUEUE.ALL from access by any user on any qmgr within the QSG

- to control access to a local queue of the same name on any of the shared queue managers within the queue sharing group where local checking is not active or where there is no local profile

for example: - qsg.LOCAL.QUEUE.EVERYWHERE protects all local queues called LOCAL.QUEUE.EVERYWHERE defined on qmgrs within the QSG.

Fully Qualified Remote Queues

- For example a profile hlq.remoteqmgrname could be used to determine who was allowed to put messages to the 'named remote qmgr in a fully qualified remote queue definition' - this means that you can control who is allowed to put to remote qmgrs for fully qualified remote queues without giving access to transmission queues

* NOTE cluster queues !!!!!

53-54 21/04/05




Access required to the profile is dependent upon the MQOPEN or MQPUT1 options:-

Option Access requiredInquire, browse READSet ALTERAll others (including all context options)

UPDATE

Access granularity on z/OS is different to that on distributed platforms, it is not as granular.

MQGET has the same access as MQPUT, so if you need to distinguish between 'putters' and 'getters' you can use alias queues to do this.



N

O

T

E

S

Access Control - MQ API Security - NotesAccess control for API requests for queues are made when a queue is opened (MQOPEN or MQPUT1) and - for permanent dynamic queues - when a queue is closed (and deleted).

Because of the different options available for opening a queue, there are several access control checks that may occur depending upon the setup of that system. This may involve checks against profiles in both the MQQUEUE and MQADMIN classes.

Don't confuse the fact that, in order to open a Queue with any of the open context options requires UPDATE authority to the profile in the MQQUEUE class, with the need to have the appropriate authority to the hlq.CONTEXT.queuename profile in the MQADMIN class in order to use the context information in anyway.

55-56 21/04/05




Queues that may required additional considerationDynamic queues

MQOPEN for dynamic queues require access to multiple profiles Model queue profile and Dynamic queue profileMQCLOSE checking for permanent dynamic queues

Alias QueuesDead Letter Queues System Queues Remote Queues



N

O

T

E

S

Access Control - MQ API Security - Notes.For model queues, there are number of security related aspects to consider:

Two checks are performed 1) Authorisation to access the Model queue 2) Authorisation to access the dynamic queue to which model queue resolves

Dynamic queues and generic names for them...There are several things to consider here too, but the main one is to ensure that the dynamic queue names have appropriate profiles defined for them. This will, most likely, involve the use of a generic profile.

Resource security checking performed during closure of permanent dynamic queues. This is performed if an application opens a permanent dynamic queue that it didn't create and then attempts to delete it...an additional security check is carried out to see if it has authority to do so...

Some applications require access to the MQMD context fields. These fields are protected by the context security profile and - for some types of access - by the queue profile

if a dynamic queue is being created and alternate userids are to be used and MQMD context fields are to be accessed. The total number of checks that might be made is 8 - if the RESLEVEL profile requires that 2 userids are checked.

Dead Letter Queues, ensure you have correct handling in place for messages put o the Dead Letter Queue due to a security failure, also ensure only authorised users can process the dead letter queue.

57-58 21/04/05



Access control - MQ API Security

MQADMIN class - the profiles look like

hlq.CONTEXT.queuenameControls access to MQMD context fieldsAccess required to profile is dependent upon which context options are requested on the MQOPEN or MQPUT1 call

hlq.ALTERNATE.USER.alternateuseridControls the use of an alternate userid To use an alternate userid you need UPDATE access to appropriate profile. You should have one profile per Queue Manager or Qsg per alternate userid



N

O

T

E

S

Access control - MQ API Security - Notes

The type of access required to the context fields varies and so the access required to the context security profile varies according to the access required. These fields include the UserIdentifier - this is typically used to determine the Alternate userid that is to be used for processing the message.

Alternate Userid profiles - These profiles are used to control who is allowed to perform work for another user, under that alternate user's authority. For example a server may be receiving work from lots of different places...it needs to be able to put those messages on behalf of the users who sent them...in order to do this the server would have to have the correct authority granted against the appropriate Alternate Userid profile. Thus, if userid SERVER54 needs to do work on behalf of USER12, SERVER54 needs UPDATE access to the hlq.ALTERNATE.USER.USER12 profile.

NOTE:- WebSphere MQ userids can be 12 characters long and all 12 characters may be used on the profile for alternate user authority. Even so, only the first 8 characters of the userid are used for any security check performed

59-60 21/04/05



Access Control - API Security - Userids

All API access control is userid based and Userids are environment dependent

Batch - Job UseridCICS - Address space userid, Transaction useridIMS - Address space userid, 'Second' useridMover - Channel Userid, MCA Userid IGQ - Intra-group Queuing Userid, Sending Queue Manager Userid

All have the possibility of using an Alternate Userid too the userid from the MQMD UserIdentifier field of the message

RESLEVEL profile controls number of userids checked

61-62 21/04/05



How to read User ID Tables

1 check 2 checks

ssid.ALTERNATE.USER.alternateuserid

ssid.CONTEXT.queuename

ssid.resourcename ID1

ID1+ID2

ID1+ID2

ID1

--- ---

1 check

Key:

Profile name

NO YES

ID1

ID1

ID1

ID1+ID2

ID1+ID2

ID1+ALT

Question to choose column

1

Alternate Userid specified on Open ?

2 checks





CONTROL No Check

ALTER No Check

YES

1 check

ID1

ID1

ID1

ID1+ID2

ID1+ID2

ID1+ALT

2 checks

ID1+ID2

ID1+ID2

ID1+ALT

2 checks

RESLEVEL to

determine number of

checks

2

Key details actual user IDs 3



N

O

T

E

S

The following pages contain the various tables detailing which user IDs are checked. These are all read in the same way which we expain here. Use the tables on the next few pages as reference material. These tables are also found in the WebSphere MQ System Setup Guide.

1) Use the question to decide which column to read. The first few tables have the same question with a YES/NO answer. The channels and IGQ tables have a few more columns to choose from based on a value that is defined on a channel (PUTAUT) or its equivalent on IGQ (IGQAUT). We will assume that the answer is YES and choose that column.

2) The RESLEVEL tables we referenced earlier determine the number of checks we will do. RESLEVEL tables are not all the same, but this generic example will do for our purposes.

3) The values in the table are short representations of the user IDs. At the bottom of each table is a key detailing exactly what these are.

4) As a final example, let us assume that no profile ssid.NO.CONTEXT.CHECKS exists so we are going to do context checking. We can read from the table that the userids ID1 and ID2 will be checked against the profile context profile.

Try it out on one of the following tables.

How to read User ID Tables - Notes

63-64 21/04/05



N

O

T

E

S

Access Controls - API Security - Userids continued...

Profile name

Alternate Userid specified on Open?

No YES

JOB

JOB

JOB

JOB

ALT

-hlq.ALTERNATE.USER.alternateuserid

hlq.CONTEXT.queuename

hlq.resourcename

Key:ALT Alternate useridJOB the TSO userid the Userid assigned to the batch job the userid assigned to the STARTED task by the STARTED class or the started procedures table

Batch



N

O

T

E

S

Access Control - API Security - Userids - continued...

1 check 2 checks



ssid.resourcename ADS

ADS+TXN

ADS+TXN

ADS

--- ---

1 check 2 checks


Key:ADS CICS address space User idALT Alternate Userid UseridTXN Userid associated with the CICS transaction

Profile name

NO YES

ADS

ADS

ADS

ADS+TXN

ADS+TXN

ADS+ALT

CICS

65-66 21/04/05



N

O

T

E

S

Access Control - API Security - Userids - continued...

Key:ALT Alternate Userid UseridREG Userid normally set through the STARTED CLASS or started procedures table or if IMS is running from a submitted job, via the USER JCL parmSEC The second userid is associated with work being done in the dependant region

1 check 2 checks



ssid.resourcename REGREG+SEC

REG+SEC

REG

--- ---

1 check 2 checks


Profile name

NO YES

REG

REG

REG

REG+SEC

REG+SEC

REG+ALT

IMS



N

O

T

E

S

Access Control - IMS second userids

1.BMP message driven and successful GET UNIQUE issued2.IFP and GET UNIQUE issued3.MPP

1.BMP message driven and successful GET UNIQUE not issued2.BMP not message driven3.IFP and GETUNIQUE not issued

1.Userid associated with the IMS transaction if the user id signed onor2.LTERM name if availableor3.PSBNAME

1.Userid associated with the IMS dependent region address space if this is not blanks/zeroesor2.PSBNAME

Type of dependent region Hierarchy for determining 2nd userid

IMS second userid determination

67-68 21/04/05



Access Control - Userids - Channel Security Choice dependant on PUTAUT

MCA User ID(MCA)

The userid specified for the MCAUSER channel attribute at the receiver, if blank , the channel initiator address space userid of the receiver or requester side.

Channel user ID (CHL)

Receiving channel using TCP/IPUserid of the channel Initiator address space of the receiver or requester end if PUTAUT parameter set to DEF or CTX.

Receiving channel using APPC(LU6.2)Requester/server channels - started from the requester, userid of the Channel Initiator address space of the receiver or requester end is usedOther channel types - the userid received from the communications system is used. If a Userid received is blank , or no userid is received then a channel userid of blank is used.

MCA Userid of the receiver or requester is used if PUTAUT set to ONLYMCA or ALTMCA.

SSL derived Userid if SSL is set on channel

Alternate User ID (ALT)

The userid specified in the UserIdentifier field in the message descriptor of the message



N

O

T

E

S

DEF CTX

1 check

2 checks

1 check

2 checks

ssid.ALTERNATE.USER.userid


ssid.resourcename

CHL

CHL

CHL

CHL

CHL CHL+MCA

CHL+MCA

CHL+MCA CHL+ALT

CHL+MCA

--- ---

ONLYMCA ALTMCA

1 check

2 checks

1 check

2 checks

--- ---

MCA

MCA

MCAMCA

MCA

MCA

MCA

MCA

MCA

MCA+ALT

PUTAUT option specified on receiver or requester channel

Key:ALT Alternate User IDCHL Channel UseridMCA MCA user ID

Profile name

Access Control - API Security Userids - continued...

Channels

69-70 21/04/05



N

O

T

E

S

Channel Security - notesReceiving channels using TCP/IP

MCA User ID(MCA)

The user ID specified for the MCAUSER channel attribute at the receiver, if blank , the channel initiator address space user ID of the receiver or requester side.


On TCP/IP, security is not supported by the communication system for the channel. If Secure Sockets Layer (SSL) is being used and a digital certificate is flowed from the partner, the Userid associated with this certificate(if installed) or the userid associated with a matching filter found be RACF's Certificate Name Filter (CNF) is used. If no associated Userid is found or if SSL is not being used then the user ID of the channel Initiator address space of the receiver or requester end is used as the channel ID on channels defined with the PUTAUT parameter set to DEF or CTX.

If the PUTAUT parameter is set to ONLYMCA or ALTMCA for the channel, the channel userid is ignored and the MCA User ID of the receiver or requester is used. This also applies to TCP/IP channels using SSL.

The use of RACF's CNF allows you to assign the same RACF userid to many remote users. For example all the users within the same organisational unit who would naturally have the same security authority. This means that the server does not have to have a copy of the certificate of every possible remote user across the world and greatly simplifies certificate management and distribution.


The user ID specified in the UserIdentifier field in the message descriptor of the message



N

O

T

E

S

Channel Security - notesReceiving channels using APPC (LU6.2)

MCA User ID(MCA)

The user ID specified for the MCAUSER channel attribute at the receiver, if blank , the channel initiator address space user ID of the receiver or requester side.


Requester/server channels - If the channel is started from the requester, there is no opportunity to receive a network Userid (channel userid). Because of this, the user ID of the channel Initiator address space of the receiver or requester end is used as the channel ID on channels defined with the PUTAUT parameter set to DEF or CTX.

If the PUTAUT parameter is set to ONLYMCA or ALTMCA for the channel, the channel userid is ignored and the MCA User ID of the receiver or requester is used.

Other channel types - If PUTAUT is set to DEF or CTX on the receiver or requester channels, the channel userid is the userid received from the communications system when the channel is initiated. If the sending channel is z/OS the channel userid received is the channel initiator address space userid of the sender. If the sending channel is on a different platform, the channel userid received is typically provided by the USERID parm of the channel definition.

If a Userid received is blank , or no user id is received then a channel userid of blank is used.



71-72 21/04/05



Userids - Client Channel Security

Choice dependant on PUTAUT

MCA User ID (MCA)The userid specified for the MCAUSER channel attribute of the server-connection, if blank, the user received from the client is used, if none sent, the channel initiator address space userid is used.The client will send the logged on user ID.

For 'old' clients user ID provided with MQ_USER_ID environment variableFor Java use Environment

Channel user ID (CHL)As for MCA channels

Alternate User ID (ALT)The userid specified in the UserIdentifier field in the message descriptor of the message



N

O

T

E

S

Alternate userid specified on open ?

DEF

1 check 2 checks 1 check 2 checks



ssid.resourcename

CHL

CHL

CHL

CHL

CHL CHL+MCA

CHL+MCA

CHL+MCA CHL+ALT

CHL+MCA

--- ---

ONLYMCA

1 check

2 checks 1 check

2 checks

--- ---

MCA

MCA

MCAMCA

MCA

MCA

MCA

MCA

MCA

MCA+ALT

PUTAUT option specified on receiver or requester channel

Key:ALT Alternate User IDCHL Channel UseridMCA MCA user ID

Profile name

Alternate userid specified on open ?NO YES NO YES

Access Control - Userids - Client Channel Security

73-74 21/04/05



Access Control - Userids - IGQ securityIntra-Group Queuing user ID (IGQ)

The user ID determined by the IGQUSER attribute of the receiving queue manager.

If this is set to blanks, the user ID of the receiving queue manager is used. However because the receiving queue manager has authority to access all queues defined to it, security checks are not performed from the receiving queue managers user ID.

Sending queue manager user ID (SND)The user ID of the queue manager within the queue- sharing group that put the message on to the SYSTEM.QSG.TRANSMIT.QUEUE

Alternate User ID (ALT)The user ID specified in the UserIdentifier field in the message descriptor of the message



N

O

T

E

S

UserID's checked for Intra-Group queuing (IGQ)

DEF CTX

1 check

2 checks

1 check

2 checks



ssid.resourcename

SND

SND

SND

SND

SND SND+IGQ

SND+IGQ

SND+IGQ SND+ALT

SND+IGQ

--- ---

ONLYIGQ ALTIGQ

1 check

2 checks

1 check

2 checks

--- ---

IGQ

IGQ

IGQIGQ

IGQ

IGQ

IGQ

IGQ

IGQ

IGQ+ALT

IGQAUT option specified on receiving queue manager

Key:ALT Alternate User IDIGQ IGQ user IDSND Sending Queue manager user ID

Profile name

Access Control - Userids - Intra-group queuing(IGQ) security

75-76 21/04/05



N

O

T

E

S

Intra-group Queuing Security - notesIntra-Group queuing user ID(IGQ)

The user ID determined by the IGQUSER attribute of the receiving queue manager.

If this is set to blanks, the user ID of the receiving queue manager is used. However because the receiving queue manager has authority to access all queues defined to it, security checks are not performed from the receiving queue managers user ID.

In this case:

If only one user ID is to be checked and the user ID is that of the receiving queue manager, no security checks will take place. This can occur when IGQAUT is set to ONLYIGQ or ALTIGQ.

If two user IDs are to be checked and one of the user IDs is that of the receiving queue manager, security checks will take place for the other user ID only. This can occur when IGQAUT is set to DEF,CTX, or ALTIGQ.

If two user IDs are to be checked and both user IDs are that of the receiving queue manager, no security checks will take place. This can occur when IGQAUT is set to ONLYIGQ

Sending queue manager user ID (SND)

The user ID of the queue manager within the queue-sharing group that put the message on to the SYSTEM.QSG.TRANSMIT.QUEUE



77-78 21/04/05



MQ Command Security - Two Types

MQCMDS class - profiles look like

hlq.verb.pkwfor example,

hlq.DEFINE.QLOCAL

hlq.DEFINE.CHANNELAccess required to profile is dependent upon the verb

Controls who is allowed to issue each individual command

MQADMIN class - command resource profiles look like

hlq.type.resourcenamefor example,

hlq.QUEUE.queuename

hlq.CHANNEL.channelnameAccess required to profile is dependent upon the verb and is usually ALTER or CONTROL

Controls which resources a user can issue given commands against.

Together they allow very granular control over MQ commands



N

O

T

E

S

MQ Command Security - NotesThese two profiles allow very granular control of the WebSphere MQ commands. There is a separate profile for each WebSphere MQ command (the verb) and target (the primary keyword), allowing each command to be controlled individually. Thus a particular userid may be able to define Local Queues but not define Remote Queues or may be able to display queues but not define queues. It is also possible to control access to the resources accessed by these commands. Thus, a user may be authorised to use the ALTER QLOCAL command but not alter a specified queue.

Clearly, there is a price to pay with respect to this control; if this type of granular control is required then many profiles may need to be defined to facilitate this access control.

The Security Chapter in the WebSphere MQ for z/OS System Setup Guide provides a table showing the profiles and access required for each profile.

79-80 21/04/05



Command checking, Cmd Resource checking

CSQINP1 & CSQINP2 - no checks

System Command Queue - MQMD.UserIdentifier

Console - Console userid

SDSF/TSO - TSO, address space userid

CSQUTIL - address space userid

CSQINPX - Channel Initiator address space userid

Access required to system queues

Access control - Command Security - Userids..



N

O

T

E

S

Userids - notesThe userid used for Command and Cmd Resource security checking varies according to the source of the command(s), though the same userid is used for both the Command and Cmd Resource checks. Commands can be issued from a variety of places and the userid that is checked depends on the source of that command, as follows:

CSQINP1 or CSQINP2No check is made as these are datasets used by the Qmgr during start up and it is recommended these datasets are protected using the normal methods.System Command Input QueueThe userid found in the UserIdentifier of the message descriptor of the message that contains the command is used. If the message does not have anything in this field a userid of BLANKs is used and passed to the security manager.

Console

The userid signed onto the console. If the console is not signed on, the DEFAULT userid from the WebSphere MQ subsystem initialisation parameter module (CSQZPARM) This default is set by the CMDUSER operand on the CSQ6SYSP macro. To issue commands from a console , the console must have the MVS SYS AUTHORITY attribute.

SDSF/TSO console ... The TSO or job userid

MGCR(SVC34) - MVS master get routine command If MGCR is used with a UToken, the userid in the UToken. If MGCR is used without a UToken, the TSO or Job userid is used.

CSQUTIL ... The job userid

CSQINPX ... The userid of the channel initiator address space.

For these programs, there are a number of queues that are used and an number of queues that are dynamically created. Appropriate profiles must be created to allows the appropriate userids to access these queues. These queues are all documented in the WebSphere MQ for z/OS System Management Guide. For all of these queues, the userid running the command utility must have UPDATE access to the appropriate queue profile.

81-82 21/04/05



Solutions

hhhhhhhhHash

Function

Plaintext

Hash Function

Symmetric Key Cryptography

CRL checkingC.R.L.Alice

Using WebSphere MQ

SSLCIPH(RC4_MD5_US)

SSLKEYR(QM1KEYRING)SSLPEER('O=IBM')SSLCAUTH(REQUIRED)

SSLCRLNL(LDAPNL)

APrivate

APublic

Asymmetric Keys

Alice's Digital Certificate

CA SigDigital Certificates

Eavesdropping

Tampering

Impersonation

Security Problems

WebSphere MQ Security - Link Level Security - SSL



N

O

T

E

S

Security Solutions with WebSphere MQ - Notes

Three main security problems, eavesdropping, tampering and impersonation.

The techniques that can be used to solve these problems;

For eavesdropping, we have symmetric key cryptography;

For tampering we have the hash function; and

For impersonation we have digital certificates, asymmetric keys and certificate revocation lists.

WebSphere MQ makes use of these techniques to provide these solutions to these security problems. One can specify which symmetric key cryptography algorithm and which hash function to use by providing WebSphere MQ with a CipherSpec. Digital Certificates and Public Keys are found in a key repository which can be specified to WebSphere MQ. We can also check that we are talking to the partner we expect to be talking to and can choose to authenticate both ends of the connection or only the SSL Server end of the connection. Also we can make use of certificate revocation lists.

83-84 21/04/05



Administration

85-86 21/04/05



Administration

MQ commands

MQ Security Messages

RESLEVEL auditing



Administration - MQ Commands

DISPLAY SECURITY

REFRESH SECURITY

RVERIFY SECURITY

ALTER SECURITY

87-88 21/04/05




DISPLAY SECURITY ALL|INTERVAL,SWITCHES,TIMEOUT

REFRESH SECURITY(*|MQADMIN,MQQUEUE,MQPROC,MQNLIST) TYPE(CLASSES|AUTHSERV|SSL) CMDSCOPE

Command qualifier * default

TYPECLASSES - default on z/OSAUTHSERV - default on non z/OS platformsSSL - refreshes cached view of the SSL key repository, locations of

LDAP servers for Certificate Name Revocation and the Key repository

CMDSCOPE - unchangedIf you change information in any of the RACF MQ Classes you must issue the following

SETROPTS RACLIST(classname,classname,...) REFRESHSETROPTS GENERIC(classname,classname,...) REFRESH

in addition to the MQ Refresh command to pick up the changes to the RACF profiles



N

O

T

E

S

Administration - NotesThere are four WebSphere MQ for z/OS commands that help you to administer security for your Queue Manager.

DISPLAY SECURITY ALL|INTERVAL|SWITCHES|TIMEOUTThis allows you to see what security is active on your Queue Manager and how frequently the internal clearout is performed of security information held by the Queue Manager.

REFRESH SECURITY(*|MQADMIN|MQQUEUE|MQPROC|MQNLIST)This command allows you to change your Queue Manager's security setup without bringing down the Queue Manager. There will be a performance impact whilst this command is being processed.

From version 5.2 of WebSphere MQ for z/OS you will now have to perform the RACF commands setropts raclist (classname,classname,...) refreshsetropts generic(classname,classname,...) refresh

at the same time you perform the WebSphere MQ Refresh security command - this is needed in order to refresh the information we now store in the RACF dataspace rather than the Queue Manager address space. THIS means some changes can be picked up before you enter the MQ REFRESH command, so plan carefully.

89-90 21/04/05




RVERIFY SECURITY(Userid,Userid,...)

ALTER SECURITY INTERVAL() TIMEOUT()

*note - CMDSCOPE



N

O

T

E

S

Administration - NotesRVERIFY SECURITY(userid,userid...)This allows you to change particular users access levels whilst the system is up and running...once the change has been made in RACF then you need to issue this command, specifying each userid that has had its authority changed.

ALTER SECURITY INTERVAL() TIMEOUT()This allows you to alter how frequently the internal clearout occurs and the period of time that information is allowed to remain in the Queue Manager unused.

CMDSCOPE keyword introduced in V5.2

The introduction of this keyword does provide the capability to issue the commands on one Qmgr in the Queue Sharing Group and have them distributed to the other Qmgrs within the same group to be processed as if they had been issued on that system.

91-92 21/04/05



Administration - Security Messages

Format for most Security Messages changed in v5.2

Qmgr Startup Security Messages written at startup

Refresh Security Security messages written during Refresh

Display Security Shortened messages issued during Display to fit in with panels



N

O

T

E

S

Security Messages - notesExamples of security messages issued at Startup and initialisation of a Qmgr. 13.35.26 STC01960 CSQH024I !MQ19 CSQHINSQ SUBSYSTEM security switch set ON,

profile 'SQ05.NO.SUBSYS.SECURITY' not found

13.35.26 STC01960 CSQH022I !MQ19 CSQHINSQ QMGR security switch set ON,

profile 'MQ19.YES.QMGR.CHECKS' found

13.35.26 STC01960 CSQH021I !MQ19 CSQHINSQ QSG security switch set OFF,

profile 'SQ05.NO.QSG.CHECKS' found

13.35.26 STC01960 CSQH021I !MQ19 CSQHIS1C CONNECTION security switch set OFF,

profile 'MQ19.NO.CONNECT.CHECKS' found

13.35.26 STC01960 CSQH024I !MQ19 CSQHIS1C COMMAND security switch set ON,

profile 'MQ19.NO.CMD.CHECKS' not found

13.35.26 STC01960 CSQH021I !MQ19 CSQHIS1C CONTEXT security switch set OFF,

profile 'MQ19.NO.CONTEXT.CHECKS' found

13.35.26 STC01960 CSQH024I !MQ19 CSQHIS1C ALTERNATE USER security switch set ON,

profile 'MQ19.NO.ALTERNATE.USER.CHECKS' not found

13.35.26 STC01960 CSQH021I !MQ19 CSQHIS1C COMMAND RESOURCES security switch set OFF,

profile 'MQ19.NO.CMD.RESC.CHECKS' found

13.35.26 STC01960 CSQH024I !MQ19 CSQHIS1C PROCESS security switch set ON,

profile 'MQ19.NO.PROCESS.CHECKS' not found

13.35.26 STC01960 CSQH024I !MQ19 CSQHIS1C NAMELIST security switch set ON,

profile 'MQ19.NO.NLIST.CHECKS' not found

13.35.26 STC01960 CSQH024I !MQ19 CSQHIS1C QUEUE security switch set ON,

profile 'MQ19.NO.QUEUE.CHECKS' not found

93-94 21/04/05



N

O

T

E

S

Security Messages - notes cont.Examples of the shortened Security messages for Display security

13.36.06 STC01960 CSQH015I !MQ19 Security timeout = 54 minutes

13.36.06 STC01960 CSQH016I !MQ19 Security interval = 12 minutes 13.36.06 STC01960 CSQH030I !MQ19 Security switches ...

13.36.06 STC01960 CSQH034I !MQ19 SUBSYSTEM: ON, 'SQ05.NO.SUBSYS.SECURITY' not found

13.36.06 STC01960 CSQH032I !MQ19 QMGR: ON, 'MQ19.YES.QMGR.CHECKS' found

13.36.06 STC01960 CSQH031I !MQ19 QSG: OFF, 'SQ05.NO.QSG.CHECKS' found

13.36.06 STC01960 CSQH031I !MQ19 CONNECTION: OFF, 'MQ19.NO.CONNECT.CHECKS' found

13.36.06 STC01960 CSQH034I !MQ19 COMMAND: ON, 'MQ19.NO.CMD.CHECKS' not found 13.36.06 STC01960 CSQH031I !MQ19 CONTEXT: OFF, 'MQ19.NO.CONTEXT.CHECKS' found

13.36.06 STC01960 CSQH034I !MQ19 ALTERNATEUSER:ON,'MQ19.NO.ALTERNATE.USER.CHECKS not found

13.36.06 STC01960 CSQH034I !MQ19 PROCESS: ON, 'MQ19.NO.PROCESS.CHECKS' not found

13.36.06 STC01960 CSQH034I !MQ19 NAMELIST: ON, 'MQ19.NO.NLIST.CHECKS' not found

13.36.06 STC01960 CSQH034I !MQ19 QUEUE: ON, 'MQ19.NO.QUEUE.CHECKS' not found

13.36.06 STC01960 CSQH031I !MQ19 COMMAND RESOURCES: OFF, 'MQ19.NO.CMD.RESC.CHECKS' found

13.36.06 STC01960 CSQ9022I !MQ19 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION



N

O

T

E

S

Security Refresh messages 13.36.30 STC01960 CSQH024I !MQ19 CSQHRFAS SUBSYSTEM security switch set ON, profile

'SQ05.NO.SUBSYS.SECURITY' not found

13.36.30 STC01960 CSQH026I !MQ19 CSQHRFAS QMGR security switch forced ON, profile

'SQ05.NO.QMGR.CHECKS' overridden

13.36.30 STC01960 CSQH026I !MQ19 CSQHRFAS QSG security switch forced ON, profile

'SQ05.NO.QSG.CHECKS' overridden

13.36.30 STC01960 CSQH021I !MQ19 CSQHRSAC CONNECTION security switch set OFF, profile

'MQ19.NO.CONNECT.CHECKS' found

13.36.30 STC01960 CSQH024I !MQ19 CSQHRSAC COMMAND security switch set ON, profile

'SQ05.NO.CMD.CHECKS' not found

13.36.30 STC01960 CSQH021I !MQ19 CSQHRSAC CONTEXT security switch set OFF, profile

'MQ19.NO.CONTEXT.CHECKS' found

13.36.30 STC01960 CSQH024I !MQ19 CSQHRSAC ALTERNATE USER security switch set ON,

profile 'SQ05.NO.ALTERNATE.USER.CHECKS' not found

13.36.30 STC01960 CSQH021I !MQ19 CSQHRSAC COMMAND RESOURCES security switch set OFF,

profile 'MQ19.NO.CMD.RESC.CHECKS' found

13.36.30 STC01960 CSQH024I !MQ19 CSQHRSAC PROCESS security switch set ON, profile

'SQ05.NO.PROCESS.CHECKS' not found

13.36.30 STC01960 CSQH024I !MQ19 CSQHRSAC NAMELIST security switch set ON, profile

'SQ05.NO.NLIST.CHECKS' not found

13.36.30 STC01960 CSQH024I !MQ19 CSQHRSAC QUEUE security switch set ON, profile

'SQ05.NO.QUEUE.CHECKS' not found

13.36.30 STC01960 CSQ9022I !MQ19 CSQHSREF ' REFRESH SECURITY' NORMAL COMPLETION

95-96 21/04/05



N

O

T

E

S

13.36.48 STC01960 CSQH015I !MQ19 Security timeout = 54 minutes

13.36.48 STC01960 CSQH016I !MQ19 Security interval = 12 minutes

13.36.48 STC01960 CSQH030I !MQ19 Security switches ...

13.36.48 STC01960 CSQH034I !MQ19 SUBSYSTEM: ON, 'SQ05.NO.SUBSYS.SECURITY' not found

13.36.48 STC01960 CSQH036I !MQ19 QMGR: ON, 'SQ05.NO.QMGR.CHECKS' overridden

13.36.48 STC01960 CSQH036I !MQ19 QSG: ON, 'SQ05.NO.QSG.CHECKS' overridden

13.36.48 STC01960 CSQH031I !MQ19 CONNECTION: OFF, 'MQ19.NO.CONNECT.CHECKS' found

13.36.48 STC01960 CSQH034I !MQ19 COMMAND: ON, 'SQ05.NO.CMD.CHECKS' not found

13.36.48 STC01960 CSQH031I !MQ19 CONTEXT: OFF, 'MQ19.NO.CONTEXT.CHECKS' found

13.36.48 STC01960 CSQH034I !MQ19 ALTERNATE USER: ON, 'SQ05.NO.ALTERNATE.USER.CHECKS'

not found

13.36.48 STC01960 CSQH034I !MQ19 PROCESS: ON, 'SQ05.NO.PROCESS.CHECKS' not found

13.36.48 STC01960 CSQH034I !MQ19 NAMELIST: ON, 'SQ05.NO.NLIST.CHECKS' not found

13.36.48 STC01960 CSQH034I !MQ19 QUEUE: ON, 'SQ05.NO.QUEUE.CHECKS' not found

13.36.48 STC01960 CSQH031I !MQ19 COMMAND RESOURCES: OFF, 'MQ19.NO.CMD.RESC.CHECKS' found

13.36.48 STC01960 CSQ9022I !MQ19 CSQHPDTC ' DISPLAY SECURITY' NORMAL COMPLETION

Security Messages - Display after Refresh

97-98 21/04/05



Administration - RESLEVEL Auditing

Reslevel Auditing

Zparm parameter RESAUDIT(YES/NO)

Determines whether a RACF RACROUTE REQUEST=AUDIT request is performed for each RESLEVEL inquiry that takes place. This request produces General Audit records (event number 27).

99-100 21/04/05



Miscellaneous



Miscellaneous

IMS Bridge

CICS Bridges

JMS

101-102 21/04/05



IMSXCF.* Profiles

Miscellaneous - IMS Bridge

IMS/ESAWebSphere MQ

XCF IMSTP

IOPCB

External Security Manager

BRIDGE

Utoken Cache

ACEE Cache

OTMA

XCF GROUP



Miscellaneous - IMS Bridge - continued...

FACILITY classIMSXCF.xcfgname.xcfmname1. WebSphere MQ/IMS connection security

IMSXCF.xcfgname.WebSphere MQ_member_nameWebSphere MQ userid requires READ access to this profile

2. IMS level of authentication - application levelIMSXCF.xcfgname.IMS_member_nameSecurity processing dependent upon WebSphere MQ'

access to this profile/SECURE OTMA

Controls userid processing done by IMS

WebSphere MQ system parameters CSQ6SYSP ... OTMACON=(,,,Age,)

103-104 21/04/05



N

O

T

E

S

IMS Bridge - Notes When using the IMS Bridge, WebSphere MQ messages are passed to the IMS system via IMS' OTMA facility.

There are several controls available within the IMS Bridge support to regulate how much security processing is carried out:

Connection security

Profile in RACF FACILITY class is IMSXCF.xcfgname.xcfmname where xcfgname is the IMS group name and xcfmname is the xcf member name for WebSphere MQ. The WebSphere MQ address space userid requires READ access to the appropriate profile in order to be able to connect to IMS systems in the relevant XCF group.

Application access control

Profile in RACF FACILITY class is IMSXCF.xcfgname.xcfmname where xcfgname is the IMS group name and xcfmname is the xcf member name for IMS.

The userid for the message is contained in the MQMD. There is also an optional password (or PassTicket) contained in the WebSphere MQ IMS header, associated with each message (MQIIH). WebSphere MQ therefore has the ability to 'sign on' users and can pass security information about that signed-on user to IMS via OTMA.

Depending upon the access that the WebSphere MQ address space userid has to the IMSXCF profile, where xcfmname is the IMS name, WebSphere MQ will take different action for the userid in the MQMD of each message which is targeted to the IMS Bridge:



N

O

T

E

S

IMS Bridge - Notes cont. WebSphere Qmgr userid has:-

Access = NONE ... A sign-on with password is performed and no security tokens are

cached for the userid

Access = READ ... A sign-on with password is performed if the userid has not

previously been seen by the Queue Manager or when the userid has been seen before

but the cached token was created with a userid only. A Utoken is cached for the userid. .

Access = UPDATE ... A sign-on without password if the userid has not been previously

seen by the Queue Manager. A Utoken is cached for this userid. .

Access = CONTROL/ALTER ... No sign-ons are performed and no Utokens are

created/cached. This option would be used in a test or development system where no

security checking is required.

105-106 21/04/05



N

O

T

E

S

IMS Bridge - Notes cont. WebSphere MQ is now able to pass security information to IMS.

The /SECURE OTMA parameter controls the use to which IMS puts the security

information, as follows:

NONE... No checks are made

CHECK ... MQMD.UserIdentifier is passed to IMS and transaction/command security is

performed by the IMS Control Region

FULL ... As for CHECK and the MQMD.Useridentifier is passed to the IMS Dependent

Region for additional security checks, for security processing that is not

handled by the IMS Control Region (eg APPC).

The WebSphere MQ OTMACON.Age parameter controls how long IMS will consider a userid and token passed from the Queue Manager to be valid.



Miscellaneous - CICS 3270 Bridge

Userid/Password supplied to 3270 transactionPassword verified if presentSurrogate checking otherwise

CICS/TSWebSphere MQBRIDGE

MONITOR

3270 TRAN

Unit of Work

TERMiNAL

CONTROL

CMDS

INQ/SETTERMINAL

BridgeExit

Formatter UNCH

ANG

ED

Browse

Reply

MQGET

START BREXIT( ... ) TRANSID( ... )

BRIDGE FACILITY

107-108 21/04/05



N

O

T

E

S

CICS 3270 Bridge - Notes

The CICS 3270 Bridge is quite similar to the IMS Bridge. However, the CICS Bridge provides fewer controls and options for security than the IMS Bridge.

When the Bridge transactions starts up, it can set the userid and password that the 3270 transaction will run with.

If a userid only is supplied, then CICS will carry out its standard surrogate checking to ensure that the userid of the Bridge transaction is authorised to use the specified userid and will then perform a sign-on without password. This make use of the SURROGAT class.

If a password (or PassTicket) is supplied with the userid, then CICS will perform a sign-on with password.

CICS provides a similar caching mechanism to the WebSphere MQ OTMACON.Age parameter. The

SIT option USRDELAY controls for how long unused user information is retained.

LOCAL - This is the default and is the lowest level of authority available. IDENTIFY - The Bridge Task is started with the authority of the userid in the MQMD. In order to use this, the userid of the Bridge Monitor (which issues the START) needs the appropriate to use the userid in the MQMD. This makes use of the SURROGAT class.VERIFY_UOW - This is the same as IDENTIFY except that a password (or PassTicket) is required, which is verified using EXEC CICS VERIFY. This is done once for each UOW and is applicable to transactions where there are several link calls within a unit of work.



Miscellaneous - CICS DPL Bridge

CICS/TS

WebSphere MQ BRIDGEMONITOR

PROGRAM

EXEC CICS START

BRIDGETASK

BROWSE

MQGET

REPLY

109-110 21/04/05



N

O

T

E

S

CICS DPL Bridge - NotesThe CICS DPL Bridge makes extensive use of EXEC CICS START commands.

The Bridge Monitor program is started via a CICS command, CKBR. One of the parameters for this command is the level of authority checking required for the Bridge Tasks. This can be one of the following:

LOCAL This is the default and is the lowest level of authority available.

IDENTIFYThe Bridge Task is started with the authority of the userid in the MQMD. In order to use this, the userid of the Bridge Monitor (which issues the START) needs the appropriate to use the userid in the MQMD. This makes use of the SURROGAT class.

VERIFY_UOWThis is the same as IDENTIFY except that a password (or PassTicket) is required, which is verified using EXEC CICS VERIFY. This is done once for each UOW and is applicable to transactions where there are several link calls within a unit of work.

VERIFY_ALL This is the same as VERIFY_UOW except that the userid/password is checked for every message, rather than every UOW.



JMS Authentication

111-112 21/04/05



What is it?

MQ Security controls connections

CICS / IMS adapters can pass transaction userids, but...

MQ assumes transaction mgr authenticated the userid

Specific userid / password authentication for WAS client connections

Provided as sample security exit, CSQ4BCX3, source and LMOD

Does USS BPX1PWD call to RACF on CHL start

Success => chl runs under authenticated userid

MQOPEN auth checksContext userid in MD

Written for WAS, but applicable to any client application

createQueueConnection(userid, password) ;createSender(requestQueue) ;

FAP UserID flow

MQ

CHIN

CHLTYPE(SVRCONN)

SCYEXIT(CSQ4BCX3)

RACFMQ

OPEN

(userid)



Summary

Security Overview


Access Control

Administration

Summary

113-114 21/04/05



BooksWebSphere MQ for z/OS System Setup Guide SC34-6052WebSphere MQ Security SC34-6079WebSphere MQ Queue Manager Clusters SC34-6061WebSphere MQ Clients SC34-6058

WebSphere MQ Security - Where to find out more

IBM Software Group



Thank You

115-116 21/04/05

GSE- WebSphere MQ zOS Security

Documents

Transcript of GSE- WebSphere MQ zOS Security