531: Controlling access to your IBM MQ system

TechCon 2021
531: Controlling
access to your IBM
MQ system
Robert Parker
Security focal, IBM MQ
parrobe@uk.ibm.com

2
TechCon 2021 Virtual Experience
Please note:
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general product direction and it should not be relied on in
making a purchasing decision.
The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver
any material, code or functionality. Information about potential future products may not be incorporated into any contract.
The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.
Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual
throughput or performance that any user will experience will vary depending upon many factors, including considerations such as
the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed.
Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.

3
—Introduction
—Access Control in MQ
—Identity
—Authentication
—Authorization
—Example security configurations
—Questions
Agenda

4
Accessing IBM MQ systems
• Applications connect to IBM MQ queue managers for different reasons
• Administration
• Monitoring
• Messaging
• IBM MQ offers a number of different options for controlling applications.
• Different levels of control can be applied to different applications

5
QMGR
Remote Client
App
Local Client
App
Network
Communications
Inter
process
Communications
• Remote apps:
• Connect over network
• Connect to MQ Channels
• Local apps:
• Connect over process pipes
• Both are subject to security checks
• But some checks are not applicable to
local apps.

6
MQ access control
Identity

7
MQ access control
Identity
Authentication

8
MQ access control
Identity
Authentication
Authorization

10
Different identities in MQ
OS User Supplied
User
Certificate
IP/
Hostname
• User the
application
runs as
• User supplied
via MQCSP
structure
• Includes
password
• IBM MQ v8+
• IP/Hostname of
connecting
application
• TLS Certificate
remote
application
provides

11
Different identities in MQ
• To authorize, MQ uses user based identification
• TLS certificates and IP/Hostname need to convert to user
• MQ provides options for this

13
Authentication
• When an application connects with an identity, you need to verify it.
• Pre-shared secrets
• Userid + password
• Exchanged certificates
• IBM MQ has multiple choices for authenticating application identities

14
Connection Authentication
• Connection authentication feature
• Allows authentication using user credentials supplied by client applications
• User ID can be validated against a number of user repositories
• OS
• LDAP
• PAM modules
• Security exits
• Allows granular controls over whether an application has to provide valid
credentials

15
Connection Authentication
CHCK…
NONE
OPTIONAL
REQUIRED
REQDADM
QMGR
Inter process
Communications
DEFINE AUTHINFO(USE.PW)
AUTHTYPE(xxxxxx)
CHCKLOCL(OPTIONAL)
CHCKCLNT(REQUIRED)
ALTER QMGR CONNAUTH(USE.PW)
REFRESH SECURITY TYPE(CONNAUTH)
MQRC_NOT_AUTHORIZED (2035)
MQRC_NONE (0)
User
Repository
Remote
Client
App
Local
Client
App

16
Channel authentication rules
• Channel authentication rules are filters that can be applied for incoming
connections
• Allowlisting – Allow connections based on a filter
• Mapping rules – Allow connections based on a filter and modify it’s identity
• Blocklisting – Block a connection based on a filter
• There are four types of filters:
• TLS Distinguished name (Issuer and Subject)
• Client User ID name
• Remote Queue Manager name
• IP/Hostname

17
• The filters are applied on channels and are applied to all incoming
connections for that channel
• The filter can be either very specific or generic.
• Specific filters take precedence over generic
• Channel authentication rules can be used to map IP/Hostname/TLS to a user

18
QMGR
SET CHLAUTH(*) TYPE(USERMAP)
CLNTUSER(*)
USERSRC(NOACCESS)
ACTION(ADD)
SET CHLAUTH(*) TYPE(USERMAP)
CLNTUSER(‘UserA’)
USERSRC(CHANNEL)
ACTION(ADD)
MQRC_NONE (0)
Remote
Client
App
Remote
Client
App

19
TLS
• MQ channels can be configured to require connecting clients to supply a
trusted certificate
• Trust of a client’s certificate follows TLS standards
• MQ can limit specific certificates to certain channels
• Via channel definition – SSLPEER
• Via channel authentication rules – SSLPEERMAP

20
TLS
QMGR
DEFINE CHANNEL(IN)
CHLTYPE(SVRCONN)
SSLCIPH(‘….’)
SSLCAUTH(REQUIRED)
SSLPEER(‘UserA’)
MQRC_NONE (0)
Remote
Client
App
Remote
Client
App
Certificate
Certificate

21
Security exits
• Security exits are bespoke, customer created exits that are ran during the
security checking.
• MQ comes with an API that can interact with MQ to provide extra control over
a connection.
• They allow customers to expand MQ's security to suit their needs.
• When ran the security exit will have access to the channel definition and
information about the incoming connection.
• It will also have a piece of data passed to it that is set on the channel – SCYDATA
• Channel exits can be created in pairs that exchange ‘messages’

22
Security exits
QMGR
Remote
Client App
DEFINE CHANNEL(IN) CHLTYPE(SVRCONN) SCYEXIT(‘Exit’)
Exit:
If time range is not 09:00 – 17:00. Block

23
Which identity will be used?
Method Notes
Client machine user ID flowed to server This will be over-ridden by anything else. Rarely do you want to trust an
unauthenticated client side user ID.
MCAUSER set on SVRCONN channel
definition
A handy trick to ensure that the client flowed ID is never used is to define
the MCAUSER as ‘rubbish’ and then anything that is not set
appropriately by one of the next methods cannot connect.
MCAUSER set by ADOPTCTX(YES) The queue manager wide setting to adopt the password authenticated
user ID as the MCAUSER will over-ride either of the above.
MCAUSER set by CHLAUTH rule To allow more granular control of MCAUSER setting, rather than relying
on the above queue manager wide setting, you can of course use
CHLAUTH rules
MCAUSER set by Security Exit Although CHLAUTH gets the final say on whether a connection is
blocked (security exit not called in that case), the security exit does get
called with the MCAUSER CHLAUTH has decided upon, and can
change it.
Highest
Lowest

25
Authorization
• Once we have an identity and authenticated it. What can they do?
• Different identities will need different levels of access
• Granting all identities all access is not recommended
• MQ bases authorization off a user identity.

26
MQ Authorization
• Controlled by creating authority records
• Specific user or group.
• Generic MQ object
• Authority is for MQ objects and what actions they can perform
• (PUT, GET, OPEN, etc)
• If a user or group does not have authority to do what they are trying to do,
they get blocked.
• Authority is built up from all authority record sources.
• Users who are members of the mqm group have full administrator access.

27
UserExternal
• MQ Authorization by default uses OS user and groups
• Requires system admins to create these.
• UserExternal mitigates this.
• Allows MQ to accept missing OS user.
• Authority records are set against the User.
• Does not support groups.
• Configured in qm.ini file:
service:
securityPolicy=UserExternal

28
Authorization
QMGR
SET AUTHREC OBJTYPE(QMGR)
GROUP(‘Group1’)
AUTHADD(CONNECT)
MQRC_NONE (0)
Authority Records
Group 1 –
Group 2 -
Remote
Client
App
Local
Client
App

30
—One size does not fit all.
—Information is current as of today.
—These are only examples and may
not meet your security
requirements or have considered
all attack vectors.
—This list is also not complete, there
are other ways you can configure
your security to meet your needs.
Disclaimer

31
Scenario
• You have:
• A single queue manager – QM1
• A single local queue – MY.QUEUE
• A single channel – ENTRY.CHANNEL
• Applications connecting remotely
• Default listener on 1414 created and started with queue manager
• You will use:
• Operating system as the user repository
• OS Groups for authorization controlling
• Users in group A should be able to PUT messages
• Users in group B should be able to GET messages

32
Scenario
QMGR
1. DEFINE QLOCAL(MY.QUEUE)
2. DEFINE CHANNEL(ENTRY.CHANNEL) CHLTYPE(SVRCONN)
3. SET AUTHREC OBJTYPE(QMGR) GROUP('groupA') AUTHADD(CONNECT,INQ)
4. SET AUTHREC OBJTYPE(QMGR) GROUP('groupB') AUTHADD(CONNECT,INQ)
5. SET AUTHREC PROFILE(MY.QUEUE) OBJTYPE(QUEUE) GROUP('groupA') AUTHADD(PUT,INQ)
6. SET AUTHREC PROFILE(MY.QUEUE) OBJTYPE(QUEUE) GROUP('groupB') AUTHADD(GET,INQ)
PUT
App
GET
App
OS repository
groupA
groupB

33
Scenario
• Stopping remote applications connecting as mqm
QMGR
PUT
App
GET
App
OS repository
groupA
groupB
SET CHLAUTH(‘*’) TYPE(BLOCKUSER) USERLIST(‘*MQADMIN’)

34
Scenario
Problems:
• The apps are not authenticating
• If one user wants to PUT/GET a message they run their app as the other user.

35
Examples:
Controlling how
applications access the
queue

36
Scenario 1 – ADOPTCTX
QMGR
PUT
App
GET
App
OS repository
groupA
groupB
ALTER AUTHINFO(‘…’) AUTHTYPE(IDPWOS) CHCKCLNT(REQUIRED) ADOPTCTX(YES)

37
Scenario 1
• No matter what user they run as, the user they supply and successfully
authenticate as will be used for authorization
• CHCKCLNT(REQUIRED) forces the apps to supply valid credentials
• Now the users can only perform the action they are supposed to
• Unless they steal the credentials of the other.

38
Scenario 2 - TLS Client Certificates
QMGR
PUT
App
GET
App
OS repository
groupA
groupB
1. ALTER CHANNEL(ENTRY.CHANNEL) CHLTYPE(SVRCONN) SSLCIPH('...') SSLCAUTH(REQUIRED)
2. SET CHLAUTH('*') TYPE(SSLPEERMAP) SSLPEER('CN=*) USERSRC(NOACCESS)
3. SET CHLAUTH('*') TYPE(SSLPEERMAP) SSLPEER('CN=userA') USERSRC(MAP) MCAUSER('userA’)
4. SET CHLAUTH('*') TYPE(SSLPEERMAP) SSLPEER('CN=userB') USERSRC(MAP) MCAUSER('userB')
Certificate
Certificate

39
Scenario 2
• Similar to ADOPTCTX, the apps are now authenticating
• They cannot impersonate the other unless they steal the credentials
• As a bonus the network communication is secured
• However, TLS certificate management is now a concern.
• Adding a new user/app requires work:
• OS entry
• AUTHREC entry
• Trust their certificate (or use same CA)
• CHLAUTH entry

40
Scenario 3 – TLS, Security exit & UserExternal
QMGR
PUT
App
GET
App
1. ALTER CHANNEL(ENTRY.CHANNEL) CHLTYPE(SVRCONN)
SSLCIPH('...') SSLCAUTH(REQUIRED) SCYEXIT(‘Exit’)
2. SET AUTHREC PROFILE(MY.QUEUE) OBJTYPE(QUEUE)
PRINCIPAL(‘userA') AUTHADD(PUT,INQ)
3. SET AUTHREC PROFILE(MY.QUEUE) OBJTYPE(QUEUE)
PRINCIPAL(‘userB') AUTHADD(GET,INQ)
Exit:
Extract CN from client certificate and set
the user as that.
Certificate
Certificate
service:
securityPolicy=UserExternal
QM.ini

41
Scenario 3
• This option fixes two issue from scenario 3:
• No need for CHLAUTH rules
• No need for adding user to OS
• But has the following considerations:
• Still need to authorize the user
• Still need to manage the certificates
• You have to maintain the security exit
• Can no longer use group authorizations

42
Recap
ADOPTCTX
• Authentication
• Requires apps to store
credentials
• User management on OS or
LDAP server
TLS Certificates &
security exit
• Adds encryption
• Security exit
maintenance
• TLS Certificate
management
• No group memberships
TLS Certificate &
CHLAUTH
• Adds encryption
• Need to map down to
a user.
• TLS certificate
management

—IBM MQ security features
—Connection authentication
—TLS
—Channel Authentication Records
—Security Exits
—Authorization
—Example security configurations

TechCon 2021 Digital Experience 44
Questions?

47
Notices and disclaimers
Copyright © 2017 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in
any form without written permission from IBM.
U.S. Government Users Restricted Rights — use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM.
Information in these presentations (including information relating to products that have not yet been announced by IBM) has been
reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have
no responsibility to update this information. This document is distributed “as is” without any warranty, either express or implied. In no
event shall IBM be liable for any damage arising from the use of this information, including but not limited to, loss of data, business
interruption, loss of profit or loss of opportunity. IBM products and services are warranted according to the terms and conditions of the
agreements under which they are provided.
IBM products are manufactured from new parts or new and used parts.
In some cases, a product may not be new and may have been previously installed. Regardless, our warranty terms apply.”
Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice.
Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented
as illustrations of how those customers have used IBM products and
the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary.
References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or
services available in all countries in which IBM operates or does business.

48
Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect
the
views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute
legal or other guidance or advice to any individual participant or their specific situation.
It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as
to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any
actions
the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or
products will ensure that the customer is in compliance with any law.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be
addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such
third-party products to interoperate with IBM’s products. IBM expressly disclaims all warranties, expressed or implied, including but not
limited to, the implied warranties of merchantability and fitness for a particular, purpose.
The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents,
copyrights, trademarks or other intellectual property right.

49
IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS, Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document
Management System™, FASP®, FileNet®, Global Business Services®,
Global Technology Services®, IBM ExperienceOne™, IBM SmartCloud®, IBM Social Business®, Information on Demand, ILOG, Maximo®,
MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®,
PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®,
SoDA, SPSS, Sterling Commerce®, StoredIQ, Tealeaf®, Tivoli® Trusteer®, Unica®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force®
and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other
product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at
"Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.

531: Controlling access to your IBM MQ system

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 531: Controlling access to your IBM MQ system

Similaire à 531: Controlling access to your IBM MQ system (20)

Plus de Robert Parker

Plus de Robert Parker (20)

Dernier

Dernier (20)

531: Controlling access to your IBM MQ system

Notes de l'éditeur