An introduction to the security capabilities of IBM MQ. Presented at the WebSphere Integration User Group UK, held on 14 July 2015 at IBM Hursley.

1. MQ Security

2. Introduction – Typical MQ
 In a Typical MQ setup there are:
● A Queue Manager
● A number of Queues and Topics
● Applications that connect to the QMGR via:
● Local Bindings
● Client connections
MQCONNX
Application (User4)
MQCONNX
Application (User2)
QMGR
Inter process
Communications
Q1..Qn

3. Introduction – Security Checks (Client)
 When a user Connects via Client:
CHLAUTH
BlockAddr
SSL/TLS
CHLAUTH
Mapping
Security Exit
MQCSP
UserID/Password
CHLAUTH
Block User
Authorisation
MQ v8 Only!

4. Authorisation
Introduction - Security Checks (Local)
 When a user Connects via Local:
MQCSP
UserID/Password
MQ v8 Only!

5. Authentication

6. Connection Authentication – Use case
 Authentication asks clients connecting to prove they are who they say they are
 Usually used in combination with authorisation to limit user's abilities
 A failure to authenticate results in an error being returned. RC=2035
 More information usually given to the MQ administrator in error logs
 Also Authorisation events written on Distributed platforms

7. QMGR
Connection Authentication – Use Case
Q1..Qn
Only Let Good
People Connect
(Bob = Good,
Tim = Bad)
Bob
Tim
I'm Bob
I'm Bob
PROVE IT

8. QMGR
Connection Authentication – Use Case
Q1..Qn
Bob
Tim
My Password is:
XXXX
Errrr....

9. Connection Authentication – Setting up
CHCK…
NONE
OPTIONAL
REQUIRED
REQDADMMQCONNX
Application (User4)
MQCONNX
Application (User2)
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

10. Connection Authentication – User repositories
 User Repository?
 Currently two options:
–Machine OAM
–LDAP server
QMGR
O/S User
Repository
(z/OS + Dist)
LDAP Server (Dist only)
DEFINE AUTHINFO(USE.OS) AUTHTYPE(IDPWOS)
DEFINE AUTHINFO(USE.LDAP) AUTHTYPE(IDPWLDAP)
CONNAME(‘ldap1(389),ldap2(389)’)
LDAPUSER(‘CN=QMGR1’)
LDAPPWD(‘passw0rd’) SECCOMM(YES)
MQCONNX
User1 + pwd1
Application (User2)

11. Assist applications that are unchanged to participate
in authentication.
Consists of:
• Client channel
security exit to
insert uid/passwd
• Command line tool
to protect passwords
in a config file
Exit: mqccred
Connection Authentication – Client-side security exit
MQCONN
Application
QMgrQMA
Network
Communications
AllQueueManagers:
User=abc
OPW=%^&aervrgtsr
QueueManager:
Name=QMA
User=user1
OPW=H&^dbgfh
AllQueueManagers:
User=abc
password=newpw
QueueManager:
Name=QMA
User=user1
password=passw0rd
Tool: runmqccred
mqccred.ini
mqccred.ini
File
permissions

12. MQ Security – Authentication via PAM
 For Unix platforms
 Configure authentication to go via PAM modules
 Gives more flexibility in mechanisms for verification and account validation
• For example, use in conjunction with nsswitch to store Unix account information in Active
Directory
 Requires queue manager command level to be updated
• Similar to NEWFUNC on z/OS
 AUTHENMD(OS|PAM) as attribute on AUTHINFO(IDPWOS) New in
FP3
strmqm –e CMDLEVEL=802 QMgr

13. Authorisation

14. Authorisation – Use Case
 Authorisation limits what connected users and inbound messages can do
• Allowed to put messages, set context fields, subscribe to topics etc
 Authority rules (ACLs) are assigned to a specific user or group.
 If a user or group does not have authority to do what they are trying to do, they get
blocked
• Permissions apply to administrative actions and to MQI operations
 Some authorisation checks are made based on the UserId in a message
• The ability to set that field during MQPUT is itself controlled by a permission
 On Distributed platforms, authorisations are controlled through an MQ component, OAM
• On z/OS, queue manager calls external security managers such as RACF via a public interface

15. Controlling authorisations on Distributed platforms
 Use the setmqaut command to make adjustments
 Also have SET AUTHREC equivalent in MQSC
• Client-mode runmqsc makes it easy to set ACLs on remote queue managers

16. MQ Security - Authorisation using LDAP
 Fixpack 2 for Unix/Linux/i builds on LDAP authentication feature
 User and group information can now be centrally located in LDAP
• No need to define OS users/groups other than mqm
• And "mqm" group loses a lot of its automatic power
 Extended attributes on AUTHINFO/IDPWLDAP object show how to discover groups
• Very similar to the authentication attributes for discovery of identities
 Requires queue manager command level to be updated
• Similar to NEWFUNC on z/OS
 Authorities can be set for individual users
• Does not use "primary groups"
setmqaut –t qmgr –p "cn=User 1,ou=users,o=ibm,c=uk" +connect
setmqaut –t qmgr –g "cn=Group 1,ou=groups,o=ibm,c=uk" +connect
strmqm –e CMDLEVEL=801 QMgr
New
in FP2

17. Adding administrators
 Users do not need to be in the 'mqm' group to do most MQ administration
 Create ACLs for other groups instead
 Explorer Wizard makes it easy
• Shows commands so you can script
 FP2 includes real script
• amqauthg.sh

18. SSL/TLS

19. TLS – Introduction
 TLS is the follow-on to SSL
• These days, trying to just say TLS and not SSL!
 Uses public-key techniques to protect data travelling across a network
• Personal certificates, signing certificates, signing and encrypting data
 SSL protocols are deprecated after all the vulnerabilities found
 But many MQ attributes still include SSL in their name for historic reasons

20. TLS – Use Case
QMGR
Q1..Qn
Bob
Tim
I don't know Bob's
password so let's
find it out by
listening in!
0@;;7A//#ca
£66!j:sdw)
What the...?

21. CipherSpec currency
 2014-2015: Security vulnerabilities with cool names
• Heartbleed, POODLE, BEAST, FREAK, Bar Mitzvah, LogJam
• Secure protocols as well as crypto algorithms found to have vulnerabilities
 Before V8.0.0.3, 44 different CipherSpecs to choose from
• SSLv3, TLSv1.0, TLSv1.2
 With V8.0.0.3, subset of just 17 CipherSpecs
• TLSv1.0, TLSv1.2
• Predominantly Ecliptic Curve, AES and SHA-2 based
 It is possible, but not recommended, to re-enable the older CipherSpecs
• Environment variable or qm.ini
 Errors if you define or start a channel with a deprecated CipherSpec
• Changes also made to older in-service versions of MQ
More in
FP3

22. Channel Authentication

23. Channel Authentication – Use Case
 CHLAUTH rules are basically filters.
 The rules tell the queue manager to will allow or block a connection that matches the filter
 The filter can be either very specific or generic.
 Types of filters:
• SSL Distinguished Name (Issuer and Subject)
• Client User ID
• Remote Queue Manager name
• IP address/Hostname (hostname was added in V8)

24. Channel Authentication – Use Case
Tim
Bob
QMGR
Q1..Qn
Only Allow
connections from
129.888.2.543
IP: 129.888.2.543
IP: 126.66.6.66
Hello I am Bob and my
password is 1234
Hello Bob!

25. Channel Authentication – Use Case
Tim
Bob
QMGR
Q1..Qn
IP: 129.888.2.543
IP: 126.666.6.666
Hello I am Bob and my
password is 1234
DENIED!
But I did
everything right!

26. Channel Authentication – Side note
 Channel Authentication rules have an order of checking:
• ADDRESSMAP
• BLOCKADDR
• SSLPEERMAP
• QMGRMAP
• USERMAP
• BLOCKUSER
 In addition if a connection matches two CHLAUTH rules where one has a specific filter
and one has a generic filter then the CHLAUTH that is SPECIFIC will be used to work out
what to do.
• For example two ADDRESSMAP:
• 1, Block where address=*
• 2, Allow where address=129.12.9.9
• Connection from 129.12.9.9 will be allowed through.

27. Channel Authentication
 When you create a CHLAUTH rule you can specify what it should do when triggered.
 The options are:
• CHANNEL – Use the userid set in the channel MCAUSER for the future checks
• MAP - Use the userid set in this CHLAUTH MCAUSER for the future checks
• NOACCESS – Block the connection
 In addition you can raise the security of the channel by setting a higher CHCKCLNT
value on the channel
• If a user connects to CHANNEL.1 they are required to pass valid credentials
• If a user connects to CHANNEL.2 they don't have to pass valid credentials.

28. Channel Authentication – MQ Explorer
 To create a new Channel Authentication rule right click on the channel
authentication folder and select “New=>Channel Authentication Record...”

29. Channel Authentication – MQ Explorer
 Next follow the steps to set up your channel authentication rule.
 In the Channel profile screen you can put the name of a channel or a generic name
• For example: “INCOMING.CHANNEL” or “System.*”
 The next screens allow you to put the filter rules in for the CHLAUTH rule which will
cause the rule to trigger
• In ADDRESSMAP rule putting address=* will cause the rule to trigger for all addresses

30. Channel Authentication – Command Line
 CHLAUTH rules are added and removed using the SET command in RUNMQSC
– The difference between adding and removing is what ACTION(x) is set to

31. AMS

32. Advanced Message Security
 AMS is an end-to-end security model, messages stay signed/encrypted through the
whole lifetime of a message
• Certain types of data fall under standards compliance that requires encryption whilst 'at rest' as
well as in transit - e.g. credit card numbers (PCI), healthcare (HIPAA)
 AMS allows messages to be selectively encrypted so that even MQ administrators cannot
see the cleartext content without the right certificate
 You create policies for a queue that describe how messages should be protected when
applications put or get messages using that queue
 The policies describe whether messages should be signed or signed + encrypted.
• Signing and encryption uses digital certificates, such as those used by TLS

33. Recommended reading
 Lots of MQ security articles on developerworks
 MQ v8 information:
https://www.ibm.com/developerworks/community/blogs/messaging/entry/where_can_i_fin
d_mq_v8_information?lang=en
 MQ v8 Security Demo:
https://www.youtube.com/watch?v=0aKamUTS4rs&feature=youtu.be

34. Bob
Tim
Questions?