Authentication in MQ

Authentication in MQ
Morag Hughson
[email protected]
Capitalware's MQ Technical Conference v2.0.1.6
Authentication in MQ - Abstract
Over the last few releases of IBM MQ, there have been a number of security
N features added that provide authentication features. This session illustrates all
those features and how they work together. This session will cover the use of
SSL/TLS on channels (and some changes in this area in MQ V8); the security exit
facility which is still available although some of the common uses for it are now built
O into the MQ product; the use of CHLAUTH rules (added in MQ V7.1 and enhanced
in MQ V8) and the MQ V8 feature Connection Authentication, which allows the
validation of user ID and password from an application at connect time.

Agenda
Authentication - Channels
SSL/TLS on MQ Channels
Some V8 updates
Channel Authentication (CHLAUTH)
Introduced in V7.1
Some V8 updates
Security Exits
Authentication - Applications
O/S Logon
Useful for locally bound applications
Not to be relied upon for client applications!
Connection Authentication using MQCONNX
Introduced in V8
Tying Authentication to Authorization
How do they all fit together?
Agenda
We’ll take a little time to remind ourselves what each of these features is and how it
N works. Then we’ll look at how these features work together and how the
authentication features ultimately can set the user ID used for authorization checks.

Authentication - Channels
MQ Application
QM1 QM2
Client
Application
Transmission MCA Queues
Queue
Application
Channels
Queues
MQ Application Transmission
Queue
Local
Authentication – Channels – Notes

First we shall look at authentication of remote partners, whether clients or remote queue
managers, which connect into your system.
N It is very important to ensure that you have good authentication mechanisms in place for any
remote partners. You must know that the connections coming into your queue manager can
be trusted.
Identification
O When an MQ application connects remotely to a queue manager it can assert an identity
across the network connection to the queue manager. This identity could be anything and so
should not be trusted without some form of queue manager side authentication.
Authentication
Authentication is the way in which a channel ensures that the other end of the channel is who
T they say they are. Channels can make use of SSL/TLS to authenticate a digital certificate sent
by the partner. In WebSphere MQ V7.1 Channel Authentication Records can be used to do
many of the jobs a security exit can do, such as allowing or blocking a channel based on IP
address, Certificate DN, Remote Queue Manager Name or Client User ID.
Once a remote partner has been authenticated, Channel Authentication Records or a security
exit can also set the identity that this channel will use for all access control checks.
E Confidentiality
In an ideal environment all channels would be running inside the enterprise with good physical
security. However, often there will be cross enterprise channels or channels running on
networks where physical security can not be guaranteed. In those cases it is worth
considering adding some level of encryption to the data flow. This can either be done in
channel exits or by using SSL/TLS on the channels.
S

Channels – Authentication Facilities
Transport Layer Security (SSL/TLS)
Using Digital Certificates
Channel Authentication Records

Introduced in WebSphere MQ V7.1
Updated in IBM MQ V8
Security Exits
Many Vendor exits available
Channels – Authentication Facilities – Notes

Over the next few pages we are going to introduce each of the following facilities
N which allow you to provide some authentication for your client or MCA channels.
The strength of the authentication provided varies by each facility so the choice of
facility should take that into account when making a business decision as to the
level of authentication required.
O

Using SSL/TLS with WebSphere MQ
Get your certificates Alice's Digital
WebSphere MQ SSL Wizard (MO04)
for Authentication Certificate
Digital Certificates SSLKEYR(QM1KEYRING)
Asymmetric Keys CA Sig
CERTLABL(‘QM1Cert') New in
Put your certificates in a place A A V8
that MQ can use Private Public
Label them how you wish SSLCRLNL(REVOKE.NL)
Decide if you need revocation
status checking (LDAP or OCSP) Revoked
Alice SSLFIPS(NO)
Decide if you need cipher spec SUITEB(NONE)
restriction (FIPS or SUITEB)
Configure your channels to SSLCIPH(RC4_MD5_US)
use SSL/TLS for Confidentiality
Symmetric Key SSLRKEYC(999 999 999)
Cryptography SSLCAUTH(REQUIRED)
… and Data Integrity Hash SSLPEER('O=IBM')
Hash Function h
Function SSLCERTI('CN=MQ CA')
Plaintext New in
V8
Using SSL/TLS with WebSphere MQ – Notes

The three main issues that Transport Level Security (SSL/TLS) addresses are Confidentiality, Data Integrity
and Authentication. The techniques that it uses to address these issues are
N – For Confidentiality, we have symmetric key cryptography with the capability to periodically reset the secret key;
– For Data Integrity we have the hash function; and
– For Authentication we have digital certificates, asymmetric keys and certificate revocation lists.
WebSphere MQ makes use of these techniques to address these security issues.

Digital Certificates and Public Keys are found in a key repository which can be specified to WebSphere MQ
O (SSLKEYR on the queue manager). The certificates have a local label which can either be specified using
CERTLABL (on the queue manager or on a per channel basis) or will default to ibmwebspheremq<qmgr-
name>. CERTLABL was added
One can specify which symmetric key cryptography algorithm and which hash function to use by providing
WebSphere MQ with a SSLCipherSpec (SSLCIPH on a channel). The secret key can be periodically reset
T by setting an appropriate number of bytes in SSLKeyResetCount (SSLRKEYC on the queue manager).
The set of cipher specs to be used by the queue manager can be restricted to a set that are compliant to the
FIPS 140-2 standard (SSLFIPS on the queue manager) available on both distributed and in WebSphere MQ
V7.1 on z/OS; or to the Suite-B standard (SUITEB on the queue manager) available on the distributed
platforms in WebSphere MQ V7.1
E We can choose to authenticate both ends of the connection or only the SSL Server end of the connection
(SSLCAUTH on a channel). Also we can make choose to do certificate revocation status checking using
either LDAP CRLs or OCSP (SSLCRLNL on the queue manager).
We can also check that we are talking to the partner we expect to be talking to by setting a CHLAUTH rule
to check the Subjects DN from the certificate (SSLPEER) and the Issuer’s DN (SSLCERTI). SSLCERTI was
S added in IBM MQ V8.

Business Partners with different CA requirements
QMgr4A QMgr QMgr4B
Only one certificate
QM's Digital
Certificate from
QM's Digital
Certificate from
to identify the queue
manager
?
VeriSign Entrust
CA CA
Sig Sig
BP A BP B
Business Partners with different CA requirements – Notes

Imagine the situation where your company has need to communicate securely with
N two difference business partners. These business partners each have a different
requirement about the Certificate Authority (CA) who signs the certificates that they
are happy to accept. In our example, Business Partner A will only accept
certificates signed by VeriSign, whereas Business Partner B will only accept
O certificates signed by Entrust.
In order for your company to be able to communicate with both of these Business
Partners, you need a certificate that is signed by VeriSign (to communicate with
Business Partner A) and a certificate that is signed by Entrust (to communicate with
T Business Partner B). However, since a queue manager can only have one
certificate, with releases prior to V8 of WebSphere MQ, you were forced into having
two queue managers, one using each certificate. This is less than ideal.
E N.B. Some people also solve this issue by using an MQIPT in front of the queue
manager.

Certificate per Channel
QMgr
ALTER CHANNEL(BPA.TO.ME) ALTER CHANNEL(BPB.TO.ME)
CHLTYPE(RCVR) QM's Digital CHLTYPE(RCVR)
Certificate
CERTLABL(‘VeriSignCert’) CERTLABL(‘EntrustCert’)
ALTER CHANNEL(TO.BPA) CA ALTER CHANNEL(TO.BPB)
CHLTYPE(SDR) Sig CHLTYPE(SDR)
CERTLABL(‘VeriSignCert’) CERTLABL(‘EntrustCert’)
QM's Digital QM's Digital
Certificate from Certificate from
VeriSign Entrust
CA CA
Sig Sig
New in
V8
BP A BP B
Certificate per Channel – Notes

What is required is the ability to indicate that this particular channel should use a
N different certificate than other channels.
This is achieved in WebSphere MQ V8 with an attribute on a channel, CERTLABL,
which can either be blank – which means use whatever the queue manager overall
is configured to use, or if provided, means that this channel should use the
O specifically named certificate.
For reasons explained a little later on, we only allow you to specify a non blank
CERTLABL at definition time if you are using a TLS cipherspec.
T

Why hasn’t IBM MQ always done this?
QM1 (Local) QM2 (Remote)

MCA SSL/TLS Handshake Flows MCA
QM2's Digital QM1's Digital
Certificate Certificate
SSL/TLS Handshake Flows
CA CA
Sig Initial data flow (inc. Chl Name) Sig
Transmission
Queue Negotiation complete
Application
Message Queues
Message
Channel
Why hasn’t IBM MQ always done this? – Notes

The SSL/TLS handshake is done as the first thing on a channel, before any of the
N internal channel FAP flows. If you have ever pointed a web-browser with a https://
address at your MQ listener port, you’ll know this. This means that the certificate is
authenticated long before the channel name at the receiver end is known. This
made it impossible to choose a certificate to be used for a receiver based on the
O channel name. The best that could have been done would have been to provide a
different certificate per port number and have several different listeners running,
each presenting a different certificate.
Over time however, as SSL/TLS is used by more and more consolidated servers,
T think HTTP server farms and large application servers, it has become necessary to
be able to separate the traffic that is going to a single server into differently
authenticated groups.
E Enhancements to the TLS protocol allow the provision of information as part of the
TLS handshake which can then be used to determine which certificate should be
used for this particular connection.
This enhancement is known as Server Name Indication (SNI).
S

Server Name Indication
Website A’s
website-a.com Digital Certificate
CA Sig
website-b.com Website B's

Digital Certificate
CA Sig
website-c.com
Website C's
Digital Certificate
CA Sig
Server Name Indication – Notes

Wikipedia provides a succinct summary of what Server Name Indication (SNI) is.
N The example on this page shows a use case where SNI would be used. We have
three websites which each have their own certificate. When they were hosted on
individual servers, then this was no problem, each web server has one certificate.
O Now let’s think about what happens if we decide to consolidate those web sites
onto a single server. How can we maintain the certificate correlation with the
website. SNI allows this to be able to happen by providing a place in the TLS
handshake for additional data to be flowed. This additional data is the hostname the
T browser was trying to connect to, thus allowing the certificate to be chosen based
off that hostname.

Using Server Name Indication (SNI) with a channel name
QM1 (Local) Channel
QM2 (Remote)
MCA TLS Handshake Flows (inc. Chl Name) MCA
Chl: TO.QM2's QM1’s Digital
Digital Certificate Certificate
TLS Handshake Flows
CA CA
Sig Initial data flow (inc. Chl Name) Sig
Transmission
Queue Negotiation complete
Application
Message Queues
Message
Both ends of the channel must be at the new

release
If old sender / client / cipherspec used
Only TLS can be used, no SSL IBM MQ only detects that it needed to supply a different
Only certain cipherspecs will be able to supply this certificate after completion of the handshake and so will
behaviour fail the connection at that point (if it hasn’t already failed
due to using the wrong certificate!)
JSSE doesn’t yet support SNI
So Java client can’t make use of it
Using Server Name Indication (SNI) with a channel name

WebSphere MQ V8 uses SNI to provide a channel name instead of a hostname.
N The sender (or client) end of the channel has been enhanced to put the channel
name into the Server Name Indication (SNI) hint for the TLS Handshake.
The receiver (or server-conn) end of the channel has been enhanced to retrieve the
channel name from the SNI hint and select the appropriate certificate based on that
O information. It is worth nothing that the channel name is now flowing in the clear,
although in a tamper-proof manner.
There are some restrictions to using this feature as listed.
T A back-level queue manager upon receiving a TLS handshake containing SNI, will
just ignore what is in the SNI (as it is defined as an optional extension) and use the
normal certificate.
If there are no channels defined on the queue manager with anything in the
E CERTLABL field, then SNI will not be used by the receiving end. This will leave the
behaviour the same as prior releases for certificate selection.

Channel Authentication Records
Set rules to control how inbound connections are treated
Inbound Clients
Inbound QMgr to QMgr channels
Other rogue connections causing FDCs
Rules can be set to

Allow a connection
Allow a connection and assign an MCAUSER
Block a connection
Ban privileged access
Provide multiple positive or negative SSL/TLS Distinguished Name matching
Mandate user ID & password checking
Rules can use any of the following identifying

characteristics of the inbound connection
IP Address
Hostnames Red items:
SSL/TLS Subject’s Distinguished Name New in V8
SSL/TLS Issuer’s Distinguished Name
Client asserted user ID
Remote queue manager name
Channel Authentication Records – Notes

Channel Authentication records allow you to define rules about how inbound
N connections into the queue manager should be treated. Inbound connections might
be client channels or queue manager to queue manager channels. These rules can
specify whether connections are allowed or blocked. If the connection in question is
allowed, the rules can provide a user ID that the channel should run with or indicate
that the user ID provided by the channel (flowed from the client or defined on the
O channel definition) is to be used.
These rules can therefore be used to
– Set up appropriate identities for channels to use when they run against the queue manager
– Block unwanted connections
T
– Ban privileged users
Which users are considered privileged users is slightly different depending on which
platform you are running your queue manager on. There is a special value
E ‘*MQADMIN’ which has been defined to mean “any user that would be privileged on
this platform”. This special value can be used in the rules that check against the
final user ID to be used by the channel – TYPE(USERLIST) rules – to ban any
connection that is about to run as a privileged user. This catches any blank user IDs
flowed from clients for example.
S

CHLAUTH – Configuration
Create rules using Pattern matching
MQSC: SET CHLAUTH Channel Name/QMgr Name/Hostname
PCF Beginning, middle, end
IP addresses (IPV4 or IPV6)
SSL Peer Name (as today)
Starting MQSC for queue manager TEST1.
SET CHLAUTH(‘*’) TYPE(ADDRESSMAP) ADDRESS(‘*’) USERSRC(NOACCESS)
SET CHLAUTH(‘*’) TYPE(BLOCKUSER) USERLIST(‘*MQADMIN’)
SET CHLAUTH(‘*’) TYPE(ADDRESSMAP) ADDRESS(‘9.20.1-3.*’) USERSRC(CHANNEL)
SET CHLAUTH(‘APP1.CHL*’) TYPE(ADDRESSMAP) ADDRESS(‘*.ibm.com’) USERSRC(CHANNEL)
SET CHLAUTH(‘*.ADMIN.*’) TYPE(SSLPEERMAP) SSLPEER(‘O=IBM,L=Hursley’) USERSRC(CHANNEL)
SET CHLAUTH(‘QM1.TO.QM2’) TYPE(QMGRMAP) QMNAME(QM1) USERSRC(MAP) MCAUSER(‘QM1USER’)
SET CHLAUTH(‘*.SVRCONN’) TYPE(USERMAP) CLNTUSER(‘mhughson’) MCAUSER(‘hughson@hursley’)
SET CHLAUTH(‘*’) TYPE(SSLPEERMAP) SSLPEER(‘O=IBM’) ADDRESS(‘9.*’) MCAUSER(‘hughson’)
CHLAUTH – Configuration – Notes

Here we show some example rules illustrating the commands used for creating the
N rules. These examples are in MQSC. There is also PCF, and this is used by the MQ
Explorer GUI.
Some of these examples illustrate the pattern matching that can be applied to
channel names, IP addresses, Hostnames, SSL/TLS DNs and remote queue
O manager names. Also we see all three types of rules, blocking channels –
USERSRC(NOACCESS); allowing channels to run with the user ID provided by the
channel – USERSRC(CHANNEL); and assigning a user ID to a channel –
USERSRC(MAP) MCAUSER(user-id). USERSRC(MAP) is the default so we also
T see in another example that it does not need to be specified on the command.

Restricting the Mappings
Rules matching on
SSL Peer
QM Name
Client User
Address/Hostname
IP
SSL Peer Name Restrict
Remote QMgr Name By
Client User ID
Mapped
Can add IP address/Hostname
Restrict where an SSL Certificate
can be used from SSL Peer X X 8
Specific IP address/Hostname
QM Name 8
Restrict where a queue manager
or client user ID can come from Client User 8
Specific IP address/Hostname IP Address
SET CHLAUTH(*) TYPE(SSLPEERMAP)

SSLPEER(‘L=”Hursley”’) MCAUSER(HURUSER) ADDRESS(‘9.20.*’)
SET CHLAUTH(*) TYPE(QMGRMAP)

QMNAME(CLUSQM*) MCAUSER(CLUSUSR) ADDRESS(‘*.ibm.com’)
Restricting the Mappings - Notes

When mapping from an SSL certificate DN, you may also want to ensure that
N certificate is being used from the correct IP address, mitigating what might happen
if a certificate is stolen.
When mapping from a queue manager name, you may also want to ensure that the
queue manager is running on the correct IP address to ensure it is not a rogue
O queue manager with the same name as one in your cluster for example.
We could imagine using the remote queue manager name or the client user ID as a
restrictor on an SSL Peer rule, however feedback from EAP did not suggest anyone
T needed it so it was not implemented. For the most part, attributes within the X509
DN will contain the same information for most practical uses. For example
CN=<Queue Manager Name>.

Fully Qualifying your Peer Name rules
Key Repository contains
All CA certs we trust SSLKEYR
Multiple CAs means possible DN clashes CA Certificate
External
External CAs CA Certificate

Internal
Checks and balances
Unlikely to have DN clashes
Internal CAs
Less rigid
May give out certs exactly as requested
May end up with clashes
Could solved in a Security Exit SET CHLAUTH(BPA.TO.ME)

MQCD.SSLPeerNamePtr TYPE(SSLPEERMAP)
MQCXP.SSLRemCertIssNamePtr SSLPEER(‘O=IBM’)
MCAUSER(BPAUSR)
SSLCERTI(‘CN=External’)
CHLAUTH rules extended
Check Subject’s DN (SSLPEER)
Check Issuer’s DN (SSLCERTI) New in
V8
Fully Qualifying your Peer Name rules – Notes

As we just saw, you can add IP address or hostname restrictors to many of the rule types to
further qualify the matching that happens.
N In the case of a Peer name map, you can fully qualify the certificate matching by providing
both the Subject’s DN (SSLPEER) and the Issuer’s DN (SSLCERTI) on a rule. SSLCERTI is
new in MQ V8.
O This is especially important if you have more than one Certificate Authority (CA) certificate in
your key repository which you may be more likely to do with the introduction of multiple
certificates for one queue manager which was a new feature in MQ V8.
However, since we now accept certificates which come from two different Certificate Authorities
(CAs) we can run foul of another issue.
T One of the benefits of Externals CAs is that they guarantee not to issue the certificates with the
same DN as another certificate that they have already issued. However, an internal CA may not be
so diligent. Some internal CAs may simply accept what the user requests as their DN, so our rogue
could obtain a certificate with non-unique DN from such a CA.
The only way to solve this issue in the past was to use a security exit, since security exits are
presented with both the issuer’s and subject’s Distinguished Name. However, we are trying to get
E away from people having to write exits for common security issues, and this very much falls into that
category.
In MQ V8, we can solve this issue by using a new attribute on CHLAUTH rules which matches the
issuer’s DN – SSLCERTI. Our CHLAUTH rules can now be fully qualified to use both SSLPEER (the
subject’s DN) and SSLCERTI (the issuer’s DN).
S

CHLAUTH – Precedence
Precedence matching
Most specific rule is matched
Chl: MY.CHANNEL
IP: 9.20.1.123
Identifying attributes are
DN: CN=Morag Hughson.O=IBM UK
Channel Name
UID: mhughson
SSL Peer Name pattern
Precedence defined for partial patterns
Remote queue manager name pattern
(MCA channels) Order Identity mechanism Notes
Client asserted user ID (MQI channels) 0 Channel Name
No pattern matching on this 1 SSL Subject’s Distinguished

Name
IP address pattern 2 SSL Issuer’s Distinguished Name
Hostname pattern (least specific) 3= Client asserted User ID Clearly several different user IDs can be
running on the same IP address.
3= Queue Manager Name Clearly several different queue managers

can be running on the same IP address
5 IP address
Within SSL Peer Name matching 6 Hostname One IP address can have multiple
hostnames
Most specific substring is
matched
CHLAUTH – Precedence – Notes

When there is more than one rule that could match the inbound connection in
N question, then we define which rule will actually be used by defining the precedence
order of what is the most specific match. The table shows that SSL Peer Names are
considered a more specific match than a queue manager name or client user ID
(because there is much more detailed information in an SSL Peer Name); and
O Hostnames are considered the least specific since clearly more than one queue
manager or client can be connecting from the same IP address/Hostname.
Hostnames are even less specific than IP addresses because an IP address can
have multiple hostnames.
T

SSL DN Precedence Mapping Example
SET CHLAUTH(*) TYPE(SSLPEERMAP) SSLPEER(‘OU=“MQ Devt”’)

MCAUSER(MQUSER)
SET CHLAUTH(*) TYPE(SSLPEERMAP) SSLPEER(‘L=“Hursley”’)

MCAUSER(HURUSER)
Order DN Substring Name
1 CN= Common name
2 T= Title
Most 3 OU= Organizational

Organizationalunit
unit
Certificate Specific 4 O= Organization
CN=Morag
Hughson
Match 5 L= Locality
6 ST=, SP=, S= State or province name
7 C= Country
CN=Morag Hughson.OU=MQ Devt.

O=IBM UK.L=Hursley.C=UK
SSL DN Precedence Mapping Example – Notes

Not only do we define the order of precedence between the various different
N identifying characteristics of an inbound connection, we also must do a similar job
for SSL Peer Name.
Here is an example to illustrate what happens when two partial patterns could both
match an inbound Distinguished Name (DN) from a client.
O
We want the most specific match to be used, so we have defined a precedent order
of what we mean by the most specific.
The table shown here that defines the precedence order is a subset of the contents
T of an SSL Peer Name in WebSphere MQ V7.1. It suffices to describe this example.
For the full table of SSL Peer Name attributes, visit Knowledge Centre here:-
http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q009860_.htm

Channel Authentication – How should I use this?
SET CHLAUTH(*) TYPE(ADDRESSMAP) ADDRESS(‘*’) USERSRC(NOACCESS) WARN(YES)

SET CHLAUTH(BPCHL.*) TYPE(SSLPEERMAP) SSLPEER(‘O=Bank of Shetland’) MCAUSER(BANK123)
SET CHLAUTH(BPCHL.*) TYPE(SSLPEERMAP) SSLPEER(‘O=Bank of Orkney’) MCAUSER(BANK456)
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(‘9.20.1-30.*’) MCAUSER(ADMUSER)
SET CHLAUTH(TO.CLUS.*) TYPE(QMGRMAP)
QMNAME(CLUSQM*) MCAUSER(CLUSUSR) ADDRESS(‘9.30.*’)
“Our
“Our
“OurBusiness
internal
Administrators
cluster
Partners
doesn’t
connect
mustuse
all
in connect
using
SSL, but
MQ using
we
Explorer,
must
SSL,ensure
but
so we
don’t
only
willuse
map
the
“We must make sure our system is completely locked down”
correct
SSL.queue
their
We access
will
managers
mapfrom
theircan
the
access
connect
certificate
by IP
into
DNs”
Address”
the cluster”
CHLAUTH – How should I use this? - Notes

Here is an example of how we expect this to be used.
N Our business requires that “We must make sure our system is completely locked
down”. So we start off with a rule that blocks everyone. Therefore anyone that
doesn’t match a more specific rule will not be allowed in.
O Our business requires that “Our Business Partners must all connect using SSL, so
we will map their access from the certificate DNs”. So we have some rules that map
specific DNs of our Business Partners to specific user IDs. Previously you might
have done this by having separate channel definitions for each BP, now if you wish
T they can come into the same receiver definition.
Our business requires that “Our Administrators connect in using MQ Explorer, but
don’t use SSL. We will map their access by IP Address”. So we have a rule that
gives them all a single administrative access user ID based on a range of IP
E addresses.
Our business requires that “Our internal cluster doesn’t use SSL, but we must
ensure only the correct queue managers can connect into the cluster”. So we have
a rule that gives access to the correctly named queue managers but only if they
S come from a recognised IP address.

Security Exits
Channel 'Gate Keeper'
Indefinite exchange of data between exits
No defined format
No communications knowledge required
Can end channel
Can set MCAUSER
Many traditional uses now covered by recent product features

Always there for niche use cases
QM1 Channel QM2

Security Exchange
MCA MCA
Transmission Security Security
Queue Exit Exit Application
Queue
Security Exits – Notes

One of the problems with authentication is that the industry could not decide how it
should be done. Different environments suit different strategies and require different
N levels of security. The most common approaches seem to be third party
authenticators such as Kerberos, SSL/TLS and Public/Private key encryption.
Originally, WebSphere MQ decided that the most flexible approach was to make
authentication a plug in service. That way each channel could have exactly the level
O of authentication it needed.
Authentication can now be done without the use of a security exit, by using SSL
and digital certificates and/or by using Channel Authentication Records.
Security exits are the first channel exits to gain control of the conversation. They
can exchange free format data with their remote partner, exchanging passwords,
T public keys etc to authenticate the remote partners request.
No knowledge of communications is required. The exit merely passes a buffer of
data back to the MCA who then transmits it to the partner machine. The data is
received by the other MCA and then passed to the other security exit.
E If the security exit agrees with the authentication then it can change the default
userid used for access control, known as the MCAUserid.
A number of security exits are shipped as samples with the product. There are also
some available for download from the supportpac web site. A number of third party
S products are also available.

Authentication – Applications
MQ Application
QM1 QM2
Client
Application
Transmission MCA Queues
Queue
Application
Channels
Queues
MQ Application Transmission
Queue
Local
Authentication – Applications – Notes

Now we shall look at authentication of applications, whether client connected or
N locally bound, which connect into your system.
It is very important to ensure that you have good authentication mechanisms in
place for any application. You must know that the connections made to your queue
manager can be trusted.
O
These applications may be business applications putting and getting messages
from application queues, or administrative applications, issuing commands to the
queue manager.
T

Applications – Authentication Facilities
O/S Logon
Useful for locally bound applications
Not to be relied upon for client applications!
Use client channel authentication
MQCONNX
Connection Security Parameters
User ID and Password
Applications – Authentication Facilities – Notes

Over the next few pages we are going to introduce each of the following facilities
N which allow you to provide some authentication for your client or locally bound
application.
O Identification
When an MQ application connects to the queue manager the O/S is interrogated to
discover the user ID that it is running under. This is used as the identity. We can
see this user ID in the context information of a message.
T Authentication
A locally bound MQ application is running against MQ under an user ID that the O/S
has provided and which has been logged onto prior to running the application. This
E may be enough authentication for a locally bound application for your business
purposes, or you may wish more.

Connection Authentication
MQCSP structure
Connection Security Parameters
User ID and password MQCNO cno = {MQCNO_DEFAULT};
MQCNO structure cno.Version = MQCNO_VERSION_5;

Connection Options
cno.SecurityParmsPtr = &csp;
WebSphere MQ V6
Passed to OAM (Dist only) MQCONNX(QMName,
Also passed to Security Exit &cno,
Both z/OS and Distributed &hConn,
MQXR_SEC_PARMS &CompCode,
&Reason);
WebSphere MQ V8
Acted upon by the queue manager (all
platforms)
MQCSP csp = {MQCSP_DEFAULT};
csp.AuthenticationType = MQCSP_AUTH_USER_ID_AND_PWD;
csp.CSPUserIdPtr = "hughson";
csp.CSPUserIdLength = 7; /* Max: MQ_CLIENT_USER_ID_LENGTH */
csp.CSPPasswordPtr = "passw0rd";
csp.CSPPasswordLength = 8; /* Max: MQ_CSP_PASSWORD_LENGTH */
Authentication - MQCONNX - Notes

On MQCONNX an application can provide a user ID and password (in the
N Connection Security Parameters (MQCSP) structure in the MQCNO), which are
passed to the queue manager at V8 to be checked (depending on whether the
queue manager is configured to do this).
The MQCSP structure was available since WebSphere MQ V6, but a security exit
O or custom OAM needed to be written to check the password. Now this is built into
the queue manager in V8.

Configuration
CHCK…
NONE
ALTER QMGR CONNAUTH(USE.PW)
Application (User4)
OPTIONAL DEFINE AUTHINFO(USE.PW) AUTHTYPE(xxxxxx)
MQCONNX REQUIRED CHCKLOCL(OPTIONAL)
User3 + pwd3 REQDADM CHCKCLNT(REQUIRED)
FAILDLAY(1) ADOPTCTX(YES)
REFRESH SECURITY TYPE(CONNAUTH)
MQRC_NOT_AUTHORIZED (2035)
Application (User2) QMgr
MQCONNX Inter process

User1 + pwd1 Communications
MQRC_NONE (0)
Configuration - Notes (1)

We’ll start with the basic configuration side of things. How do I turn on this connection
N authentication feature on the queue manager.
On the queue manager object there is a new attribute called CONNAUTH (short for connection
authentication) which points to an object name. The object name it refers to is an
authentication information object – one of two new types. There are two existing types of
O authentication information objects from earlier releases of WebSphere MQ, these original two
types cannot be used in the CONNAUTH field.
The two new types are similar in quite a few of the basic attributes so we will look at those first.
We’ll come back to more of the attributes later. We show here a new authentication information
object which has two fields to turn on user ID and password checking, CHCKLOCL (Check
T Local connections) and CHCKCLNT (Check Client connections). Changes to the configuration
of this must be refreshed for the queue manager to pick them up.
Both of these fields have the same set of attributes, allowing for a strictness of checking. You
can switch it off entirely with NONE; set it to OPTIONAL to ensure that if a user ID and
E password are provided by an application then they must be a valid pair, but that it is not
mandatory to provide them – a useful migration setting perhaps; set it to REQUIRED to
mandate that all applications provide a user ID and password; and, only on Distributed,
REQDADM which says that privileged users must supply a valid user ID and password, but
S non-privileged users are treated as per the OPTIONAL setting.

Any application that does not supply a user ID and password when required to, or
N supplies an incorrect combination even when it is optional will be told 2035
(MQRC_NOT_AUTHORIZED). N.B. When password checking is turned off using
NONE – then invalid passwords will not be detected.
Any failed authentications will be held for the number of seconds in the FAILDLAY
O attribute before the error is returned to the application – just some protection
against a busy loop from an application repeatedly connecting.

So we have seen that we can configure our queue manager to mandate user IDs and
N passwords are provided by certain applications. We know that the user ID that the
application is running under may not be the same user ID that was presented by the
application along with a password. So what is the relationship of these user IDs to the
ones used for the authorization checks when the application, for example, opens a
queue for output.
O There are two choices, in fact, controlled by an attribute on the authentication
information object – ADOPTCTX.
You can choose to have applications provide a user ID and password for the purposes
of authenticating them at connection time, but then have them continue to use the user
T ID that they are running under for authorization checks. This may be a useful stepping
stone when migrating, or even a desirable mode to run in, perhaps with client
connections, because authorization checks are being done using an assigned
MCAUSER based on IP address or SSL/TLS certificate information.
E Alternatively, you can choose the applications to have all subsequent authorization
checks made under the user ID that you authenticated by password by selecting to
adopt the context as the applications context for the rest of the life of the connection.
If the user ID presented for authentication by password is the same user ID that the
S application is also running under, then of course this setting has no effect.

User Repositories
DEFINE AUTHINFO(USE.OS) AUTHTYPE(IDPWOS)
DEFINE AUTHINFO(USE.LDAP) AUTHTYPE(IDPWLDAP)
CONNAME(‘ldap1(389),ldap2(389)’)
LDAPUSER(‘CN=QMGR1’)
LDAPPWD(‘passw0rd’) SECCOMM(YES)
LDAP Server (Dist only)
QMgr
Application (User2)
On z/OS passphrases
MQCONNX can be used
User1 + pwd1
O/S User
Repository
(z/OS + Dist)
User Repositories – Notes

So far we have spoken about user ID and password authentication without mentioning what is
actually doing the authentication. We’ve also shown that there is a new type of authentication
N information object without showing you the object type. Here we introduce two new object
types of authentication information objects.
The first type is used to indicate that the queue manager is going to use the local O/S to
authentication the user ID and password. This type is IDPWOS. This includes the use of
password phrases on z/OS
The second type is used to indicate that the queue manager is going to use an LDAP server
O to authenticate the user ID and password. This type is IDPWLDAP and is not applicable on
z/OS.
Only one type can be chosen for the queue manager to use by naming the appropriate
authentication information object in the queue manager’s CONNAUTH attribute.
We have already covered everything there is to say about the configuration of the O/S as the
T user repository as the common attributes are all there is for the O/S. There is more to say
about the LDAP server as an option though.
Some of the LDAP server configuration attributes are probably fairly obvious. The CONNAME
is how the queue manager knows where the LDAP server is, and SECCOMM controls
whether connectivity to the LDAP server will be done using SSL/TLS or not. The LDAPUSER
and LDAPPWD attributes are how the queue manager binds to the LDAP server so that it can
E look-up information about user records. It is likely this may be a public area of an LDAP
server, so these attributes may not be needed.
It is worth highlighting that the CONNAME field can be used to provide additional addresses to
connect to for the LDAP server in a comma-separated list. This can aid with redundancy if the
LDAP server does not provide such itself.
S

Local Bindings Authorization
Method Notes
User ID running the application process Authenticated when the user ID logged onto the
machine
User ID set by ADOPTCTX(YES) The queue manager wide setting to adopt the
password authenticated user ID as the user to be
used will over-ride the above.
Application (User2) QMgr
MQCONNX Inter process

User1 + pwd1 Communications
Q1 Authority
Checks
Local Bindings Authorization - Notes

A locally bound application is one that is running on the same machine as the
N queue manager and using Inter-process communication to connect and not sockets
and a channel. When an application is locally bound, the identity used for
authorization checks for all the resources that application wants to use is assigned
in one of the following ways:-
O The user ID that the process running the application is running under, will be used
for authorization checks. This user ID has been authenticated by means of that user
ID logging on to the O/S.
T Alternatively, if the application provided a user ID and password for authentication,
and the queue manager is configured to check these, there is a setting called
ADOPTCTX (Adopt Context) and if that is set to YES, the authentication user ID will
be user for authorization checks. This user ID may well be different to the one the
E process running the application is running under.

Client Bindings Authorization
Method Notes
Client machine user ID flowed to This will be over-ridden by anything else. Rarely do you want
server to trust an unauthenticated client side user ID.
MCAUSER set on SVRCONN A handy trick to ensure that the client flowed ID is never used
channel definition 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.
Client Bindings Authorization - Notes

A client bound application is one that is connecting to the queue manager using a
N channel and therefore a socket. When an application is running as a client, the
identity used for authorization checks for all the resources that application wants to
use is assigned in one of the ways shown in the table.
There are numerous ways that the running user can be set for a SVRCONN
O channel, i.e. the user which is representing the client application when it is running
on the queue manager machine. The ADOPTCTX(YES|NO) attribute that we just
saw is yet another one. How do all these different ways of setting the MCAUSER on
the SVRCONN interact.
T
There is an order of events and certain ways of setting the MCAUSER over-ride
others. The table shows the order.

Security Scale - None!!!
MQ Client Application (CLNTUSR)
QM1
MQCONN MCA MCA
MQOPEN Client process user ID sent

MQPUT
Application
MQOPEN User Data (MQPUT) Queues
MQGET User Data (MQGET)
Channel MCAUSER = CLNTUSR
Client Channel
Client side user is used without any authentication at all
So client machine can choose to assert anything it wants
Simple mitigation - add defined MCAUSER of an unknown ID to block this off

…. and pick something even just slightly higher on the scale!
Security Scale - Low

QM1
MQCONN MCA MCA
IP address is
9.20.21.22

MQPUT
Application
Channel MCAUSER = IBMUSER
CLNTUSR
Client Channel
Simple IP address filtering
Not really authentication CHLAUTH Rules
SET CHLAUTH(*) TYPE(ADDRESSMAP)
Better than nothing? ADDRESS('9.20.21.22')
MCAUSER('IBMUSER')

Security Scale - Medium QMgr Settings 'USE.PW' Settings
AUTHTYPE(IDPWOS)
CHCKCLNT(REQUIRED)
MQ Client Application (CLNTUSR) CONNAUTH('USE.PW') ADOPTCTX(YES)
QM1
MQCONNX MCA MCA
(with MQCSP)
->USR123

MQPUT MQCSP User ID and Password
Application
USR123
Client Channel
User ID & Password checking
CHLAUTH Rules
With IP address filtering SET CHLAUTH(*) TYPE(ADDRESSMAP)
For an extra level of proof ADDRESS('9.20.21.22')
USERSRC(CHANNEL)
Security Scale - High QMgr Settings

SSLKEYR(QM1KEYRING)
CERTLABL('QM1Cert')
QM1
MQCONN MCA MCA
QM1's Digital
SSL/TLS Handshake Flows Client's Digital
CA Sig CA Sig

IP address is
MQPUT 9.20.21.22
Application
IBMUSER
Client Channel
Digital Certificate for Authentication
Set MCAUSER based on DN CHLAUTH Rules
Fully qualified DN checking SET CHLAUTH(*) TYPE(SSLPEERMAP)
SSLPEER('O=IBM') SSLCERTI('CN=MQ CA')
Address restrictor for extra proof ADDRESS('9.20.21.22')
MCAUSER('IBMUSER')

Security Scale - Full QMgr Settings
SSLKEYR(QM1KEYRING)
'USE.PW' Settings
AUTHTYPE(IDPWOS)
CERTLABL('QM1Cert') CHCKCLNT(REQUIRED)
MQ Client Application (CLNTUSR) CONNAUTH('USE.PW') ADOPTCTX(YES)
QM1
MQCONNX MCA MCA
(with MQCSP) QM1's Digital
SSL/TLS Handshake Flows Client's Digital
->USR123
CA CA
Sig Client process user ID sent Sig
MQOPEN
IP address is
MQPUT MQCSP User ID and Password 9.20.21.22
Application
Channel MCAUSER = USR123
CLNTUSR
Client Channel
Certificates and Password Validation
CHLAUTH Rules
SET CHLAUTH(*) TYPE(SSLPEERMAP)
Set MCAUSER based on
SSLPEER('O=IBM') SSLCERTI('CN=MQ CA')
Either DN as before ADDRESS('9.20.21.22')
Or validated user ID USERSRC(CHANNEL)
Putting it all together - Notes

The process of authenticating a locally bound application is fairly simple as we saw
N on earlier pages.
However, the process of authenticating a client application has a number of
possible features. Here we show how they can all be used together if you wish, or
how you can dial down to only features that meet your business requirements.
O

MQ Security History and Summary
IBM MQ provides a scale of authentication features
From simple IP filtering …
AMS
… through user ID and password validation … Embedded
… to the strength of digital certificates with TLS channels CHLAUTH
CONNAUTH
Exit points remain for provision of exceptional needs Certificate CHLAUTH
MQSC Cluster Labels hostnames
Auth Queue
Choose the feature(s) SSL Refresh
OCSP cmds ACLs
that meets SSL on Channels

FIPS on
FIPS
your needs
*SYSTEM
keystores Dist SHA-2
on z
V7.5
V8
on IBM i
GSKit
MQCSP on Win V7.1
Channel Exits V7.0.1
V7
Authorization
provided from V6
day 1
V5.3
V5.2
V5 V5.1
V2.1
V1.1
V2 IBM MQ
V1 IBM MQ Advanced
IBM Message Security
WebSphere MQ
IBM MQSeries
1990s 2000s 2010s

Authentication in MQ - Abstract

Uploaded by

Copyright:

Available Formats

Authentication in MQ - Abstract

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Authentication in MQ - Abstract

Uploaded by

Copyright:

Available Formats

Capitalware's MQ Technical Conference v2.0.1.6

Capitalware's MQ Technical Conference v2.0.1.6

Tying Authentication to Authorization

How do they all fit together?

Capitalware's MQ Technical Conference v2.0.1.6

Capitalware's MQ Technical Conference v2.0.1.6

Capitalware's MQ Technical Conference v2.0.1.6

Authentication – Channels – Notes

Capitalware's MQ Technical Conference v2.0.1.6

Channel Authentication Records

Capitalware's MQ Technical Conference v2.0.1.6

Channels – Authentication Facilities – Notes

Capitalware's MQ Technical Conference v2.0.1.6

Using SSL/TLS with WebSphere MQ – Notes

WebSphere MQ makes use of these techniques to address these security issues.

Capitalware's MQ Technical Conference v2.0.1.6

Capitalware's MQ Technical Conference v2.0.1.6

Business Partners with different CA requirements – Notes

Capitalware's MQ Technical Conference v2.0.1.6

Capitalware's MQ Technical Conference v2.0.1.6

Certificate per Channel – Notes

Capitalware's MQ Technical Conference v2.0.1.6

QM1 (Local) QM2 (Remote)

Capitalware's MQ Technical Conference v2.0.1.6

Why hasn’t IBM MQ always done this? – Notes

Capitalware's MQ Technical Conference v2.0.1.6

website-b.com Website B's

Capitalware's MQ Technical Conference v2.0.1.6

Server Name Indication – Notes

Capitalware's MQ Technical Conference v2.0.1.6

Both ends of the channel must be at the new

Capitalware's MQ Technical Conference v2.0.1.6

Using Server Name Indication (SNI) with a channel name

Capitalware's MQ Technical Conference v2.0.1.6

Rules can be set to

Rules can use any of the following identifying

Capitalware's MQ Technical Conference v2.0.1.6

Channel Authentication Records – Notes

Capitalware's MQ Technical Conference v2.0.1.6

Starting MQSC for queue manager TEST1.

SET CHLAUTH(‘*’) TYPE(ADDRESSMAP) ADDRESS(‘*’) USERSRC(NOACCESS)

SET CHLAUTH(‘*’) TYPE(BLOCKUSER) USERLIST(‘*MQADMIN’)

SET CHLAUTH(‘*’) TYPE(ADDRESSMAP) ADDRESS(‘9.20.1-3.*’) USERSRC(CHANNEL)

SET CHLAUTH(‘APP1.CHL*’) TYPE(ADDRESSMAP) ADDRESS(‘*.ibm.com’) USERSRC(CHANNEL)

SET CHLAUTH(‘*.ADMIN.*’) TYPE(SSLPEERMAP) SSLPEER(‘O=IBM,L=Hursley’) USERSRC(CHANNEL)

SET CHLAUTH(‘QM1.TO.QM2’) TYPE(QMGRMAP) QMNAME(QM1) USERSRC(MAP) MCAUSER(‘QM1USER’)

SET CHLAUTH(‘*.SVRCONN’) TYPE(USERMAP) CLNTUSER(‘mhughson’) MCAUSER(‘hughson@hursley’)

SET CHLAUTH(‘*’) TYPE(SSLPEERMAP) SSLPEER(‘O=IBM’) ADDRESS(‘9.*’) MCAUSER(‘hughson’)

Capitalware's MQ Technical Conference v2.0.1.6

CHLAUTH – Configuration – Notes

Capitalware's MQ Technical Conference v2.0.1.6

SET CHLAUTH(*) TYPE(SSLPEERMAP)

SET CHLAUTH(*) TYPE(QMGRMAP)

Capitalware's MQ Technical Conference v2.0.1.6

Restricting the Mappings - Notes

Capitalware's MQ Technical Conference v2.0.1.6

External CAs CA Certificate

SET CHLAUTH(‘’) TYPE(ADDRESSMAP) ADDRESS(‘’) USERSRC(NOACCESS)

SET CHLAUTH(‘’) TYPE(BLOCKUSER) USERLIST(‘MQADMIN’)

SET CHLAUTH(‘’) TYPE(ADDRESSMAP) ADDRESS(‘9.20.1-3.’) USERSRC(CHANNEL)

SET CHLAUTH(‘APP1.CHL’) TYPE(ADDRESSMAP) ADDRESS(‘.ibm.com’) USERSRC(CHANNEL)

SET CHLAUTH(‘.ADMIN.’) TYPE(SSLPEERMAP) SSLPEER(‘O=IBM,L=Hursley’) USERSRC(CHANNEL)

SET CHLAUTH(‘’) TYPE(SSLPEERMAP) SSLPEER(‘O=IBM’) ADDRESS(‘9.’) MCAUSER(‘hughson’)

SET CHLAUTH() TYPE(ADDRESSMAP) ADDRESS(‘’) USERSRC(NOACCESS) WARN(YES)