This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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.
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.
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.
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 .
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(...)
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.
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.
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
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.
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 **
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)
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
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
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
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.
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(PRO2.NO) LIST
SEARCH CLASS(MQADMIN) MASK(PRO3.NO) LIST
SEARCH CLASS(MQADMIN) MASK(PRO1.YES) LIST
SEARCH CLASS(MQADMIN) MASK(PRO2.YES) LIST
SEARCH CLASS(MQADMIN) MASK(PRO3.YES) LIST
and by checking the output.
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
Example3 of the use of Switch ProfilesThree WebSphere MQ subsystems have been defined called PROD, DEVT and TEST ( in a QSG called PDT1 ).
All the RACF classes have been defined and activated.
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.
So how do these requirements relate to switch profiles ?
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
and by checking the output.
You then need to define a QSG profile to turn off Qmgr checking using the RACF command
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
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.
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 .
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.*
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
RACF access level Level of checking
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.
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
RACF access level Level of checking
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
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
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.
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
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
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.
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
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.
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
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
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.
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
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
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
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.
Channel user ID (CHL)
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.
Alternate User ID (ALT)
The user ID specified in the UserIdentifier field in the message descriptor of the message
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.
Channel user ID (CHL)
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.
Alternate User ID (ALT)
The user ID specified in the UserIdentifier field in the message descriptor of the message
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
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
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
Alternate User ID (ALT)
The user ID specified in the UserIdentifier field in the message descriptor of the message
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.
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.
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.
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.
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.
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,
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
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).
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:
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.
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.