Securing Queue Manager for Client Connection: Part 2 – Using SSL with CHLAUTH

Welcome to the 2nd Part of this Securing Queue Manager for Client Connection blog series. In the first part Part 1 – Using SSL we focused on enabling SSL communication between client (MQExplorer) and Queue Manager. But it provided complete administrative access for connections on the server-connection channel created for the purpose. We had disabled CHLAUTH and CONNAUTH security features and at the same time by-passed authorization by setting the MCAUSER of the channel to mqadmin (a privileged user belonging to mqm group).

Now, in this second part, we will enable CHLAUTH security and use it to restrict connections from client based on SSL Certificate DN and the Issuer’s DN as well as provide the client with different kind of security access depending on it.

For the illustration purpose, we will try to implement the below mentioned security access for the different purposes identified –> Administration / Monitoring / Application Usage. In this blog, we will configure for Administration and Monitoring purposes.

For recreating these steps, pre-required softwares are

  • OpenSSL to sign the certificates
  • MQ v8 or later installed on the Server (Linux machine)
  • MQ Explorer installed on client machine (For only MQ Explorer installation use SupportPac MS0T)
  • Part-1 of this blog series is completed

QM-access-types

1. Creating Groups & Users on MQ Linux Server

We are going to create 3 groups and users for this purpose as provided below

access-setup

Note: Although for set of group / user we need to provide full administration access, we are going to do it without making the user as privilege user, that is without making him  a member of mqm group

  • Logon to the MQ server and switch to root account
  • Create the groups as per above table
# groupadd mqsupp
# groupadd mqmon
  • Create the users and add them to appropriate groups as per above table
# useradd -g mqsupp yuvaraj
# useradd -g mqmon monusr1
  • Exit from root account

2. Generating SSL Certificate for the different Clients (Administrative / Monitoring )

  • Setting up the directory for storing the keys
# cd /ssl
# mkdir mqsupp mqmon
  • Create a key database for the different user account, using the following command
# runmqckm -keydb -create -db /ssl/mqsupp/yuvaraj.jks -pw admin 
     -type jks -stash
# runmqckm -keydb -create -db /ssl/mqmon/monusr1.jks -pw admin 
     -type jks -stash
  • Create Certificate Signing Request (CSR) for the respective user account’s using the following command
# runmqckm -certreq -create -db /ssl/mqsupp/yuvaraj.jks -pw admin 
    -type jks -label yuvaraj 
    -dn "CN=Yuvaraj C P,O=NA ,OU=Training,OU=MQ Support,C=IN" 
    -size 2048 -sig_alg SHA256_WITH_RSA 
    -file /ssl/mqsupp/yuvaraj_csr.arm

# runmqckm -certreq -create -db /ssl/mqmon/monusr1.jks -pw admin 
    -type jks -label monusr1 
    -dn "CN=Monitoring User 1 ,O=NA,OU=Training,OU=MQ Mon,C=IN" 
    -size 2048 -sig_alg SHA256_WITH_RSA 
    -file /ssl/mqmon/monusr1_csr.arm
  • Sign the respective user account’s CSR using the Intermediate CA’s private key to generate the certificate for the CSR and when prompted for pass phrase of Intermediate CA’s private key, use the value provided while creating it.
# cd /ssl/ca
# openssl ca -config intermediate/openssl.cnf -extensions usr_cert 
    -days 375 -notext -md sha256 -in /ssl/mqsupp/yuvaraj_csr.arm 
    -out /ssl/mqsupp/yuvaraj_cert.arm
# openssl ca -config intermediate/openssl.cnf -extensions usr_cert 
    -days 375 -notext -md sha256 -in /ssl/mqmon/monusr1_csr.arm 
    -out /ssl/mqmon/monusr1_cert.arm
  • Receive the Intermediate CA signed certificate into the respective user account’s key database using the following command
# runmqckm -cert -receive -file /ssl/mqsupp/yuvaraj_cert.arm 
     -db /ssl/mqsupp/yuvaraj.jks -pw admin -type jks -format ascii
# runmqckm -cert -receive -file /ssl/mqmon/monusr1_cert.arm 
     -db /ssl/mqmon/monusr1.jks -pw admin -type jks -format ascii
  • Add the Intermediate & Root CA’s certificate to the respective user acc0unt’s key database using the following command
# runmqckm -cert -add -db /ssl/mqsupp/yuvaraj.jks -pw admin 
       -label nebula-intermediate 
       -file /ssl/ca/intermediate/certs/intermediate.cert.der -format ascii
# runmqckm -cert -add -db /ssl/mqsupp/yuvaraj.jks -pw admin 
       -label nebula-root -file /ssl/ca/certs/ca.cert.der -format ascii
# runmqckm -cert -add -db /ssl/mqmon/monusr1.jks -pw admin 
       -label nebula-intermediate 
       -file /ssl/ca/intermediate/certs/intermediate.cert.der -format ascii
# runmqckm -cert -add -db /ssl/mqmon/monusr1.jks -pw admin 
       -label nebula-root -file /ssl/ca/certs/ca.cert.der -format ascii
  • FTP the directory containing the key databases we created for different user account’s under /ssl/ to the respective client machine using suitable ftp client.

3. Enabling Client Connection for Privileged User Account 

Pre-requisites: MQ v8 server or above is installed in the linux machine and user account mqadmin (member of mqm group) is setup with home directory as /home/mqadmin. Part-1 of this blog series is completed.

All the below steps are to be executed in the scripting window (using runmqsc) of the queue manager

  • Create and start the listener object to specify the port on which the queue manager is to listen for client connections (if not created already)
DEFINE LISTENER(TCP.LISTENER) TRPTYPE(TCP) +
   CONTROL(QMGR) PORT(1909)
START LISTENER(TCP.LISTENER)
  • Modify the queue manager property to enable CHLAUTH and disable CONNAUTH security features and to specify the location of the SSL key database that is to be used by the QM for SSL Communication, as shown below
ALTER QMGR CERTLABL('secureqm') +
    SSLKEYR('/home/mqadmin/ssl/secureqm/key') +
    CHLAUTH(ENABLED) CONNAUTH(' ')
  • Create a new Server Connection channel that is to be used only by privileged user account for administering queue manager. By default block all connections on this channel and hence the MCAUSER attribute of this channel is set to ‘nobody’. We will be overriding this value using the appropriate Channel Authentication record depending on the specific value of client’s SSL DN and Issuer DN.
DEFINE CHANNEL(PRIV.ADMIN.SVRCONN) CHLTYPE(SVRCONN) + 
  MCAUSER('nobody') SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)
  • Create a Channel Authentication Rule as Back-stop rule (refer CHLAUTH – the back-stop rule (IBM Developerworks Blog)) to block everyone connecting to the queue manager. The CHLAUTH rule created by default with QM only blocks privileged user account, where as the new rule that we are creating is to block everyone.
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) + 
    DESCR('Back-stop rule to block everyone') WARN(NO) ACTION(ADD)
  • Create a new CHLAUTH record to override the existing default rule that blocks all connections by privileged user account
SET CHLAUTH('PRIV.ADMIN.SVRCONN') TYPE(BLOCKUSER) +
  USERLIST('anyuser') + 
  DESCR('Rule to override blocking of privilege user account') + 
  WARN(NO) ACTION(ADD)
  • Create  a new Channel Authentication Rule to allow only administrator’s to connect to our queue manager for administration purpose. In our case, the user account of administrator is mqadmin
SET CHLAUTH('PRIV.ADMIN.SVRCONN') TYPE(SSLPEERMAP) + 
SSLPEER('CN=nebula-mqexplorer, OU=Training, O=NA') + 
USERSRC(MAP) MCAUSER('mqadmin') DESCR('SSL Auth for privilege user') + 
SSLCERTI('CN=Nebula Intermediate CA, OU=Training, O=Nebula Academy') + 
ACTION(ADD)
  • Refresh the security using the command
REFRESH SECURITY
  • Connect to SECUREQM from MQ Explorer on the client machine.Follow the steps provided in section 5 of Part-1 of this blog series, and using the server-connection channel PRIV.ADMIN.SVRCONN
  • On successful connection from MQ Explorer, check the channel status on MQ Linux server for the SECUREQM as shown below. Check the SSLPEER, SSLCERTI, SECPROT and MCAUSER attribute values on the channel status output
DIS CHS(PRIV.ADMIN.SVRCONN) ALL

AMQ8417: Display Channel Status details.
 CHANNEL(PRIV.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
 BUFSRCVD(66) BUFSSENT(69)
 BYTSRCVD(17652) BYTSSENT(41280)
 CHSTADA(2017-03-08) CHSTATI(13.01.21)
 COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
 COMPRATE(0,0) COMPTIME(0,0)
 CONNAME(192.168.203.1) CURRENT
 EXITTIME(0,0) HBINT(300)
 JOBNAME(000022C300000004) 
 LOCLADDR(::ffff:192.168.203.143(1909))
 LSTMSGDA(2017-03-08) LSTMSGTI(13.01.23)
 MCASTAT(RUNNING) MCAUSER(mqadmin)
 MONCHL(OFF) MSGS(67)
 RAPPLTAG(MQ Explorer 8.0.0) SECPROT(TLSV12)
 SSLCERTI(E=reachnebula@gmail.com,CN=Nebula Intermediate CA,OU=Training,O=Nebula Academy,ST=TamilNadu,C=IN)
 SSLKEYDA( ) SSLKEYTI( )
 SSLPEER(SERIALNUMBER=10:01,CN=nebula-mqexplorer,OU=Training,O=NA,C=IN)
 SSLRKEYS(0) STATUS(RUNNING)
 STOPREQ(NO) SUBSTATE(RECEIVE)
 CURSHCNV(1) MAXSHCNV(10)
 RVERSION(08000002) RPRODUCT(MQJB)

4. Granting Requisite Access to User Account

  • We are not going to add the user accounts that was created for queue manager administrative purpose to mqm group. Instead we are going to create Access Control List (ACL) for administrative access using setmqaut command
  • Copy the scripts grantAdminAccess.odt & grantReadAccess.odt attached in the appendix section of this blog as /home/mqadmin/grantAdminAccess.sh/home/mqadmin/grantReadAccess.sh respectively

grantAdminAccess.sh

#!/bin/sh
## These commands give group 'mqsupp' full administrative access 
## for the QM to specified group
## Usage:
## grantAdminAccess.sh <QM Name> <Group>
## 
## <QM Name> : Name of the queue manager for which admin access is required
## <Group> : Group to which administrative access is to be granted

if [ $# -lt 2 ]
 then
 echo "Incorrect number of arguments supplier"
 echo "Usage: grantAdminAccess.sh <QM Name> <Group>"
 exit 1
 else
 setmqaut -m $1 -t qmgr -g $2 +connect +inq +alladm
 setmqaut -m $1 -n "**" -t q -g $2 +alladm +crt +browse
 setmqaut -m $1 -n "**" -t topic -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t channel -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t process -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t namelist -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t authinfo -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t clntconn -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t listener -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t service -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t comminfo -g $2 +alladm +crt

## The following commands provide administrative access for MQ Explorer.
 setmqaut -m $1 -n SYSTEM.MQEXPLORER.REPLY.MODEL -t q -g $2 +dsp +inq +get
 setmqaut -m $1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -g $2 +dsp +inq +put
fi

grantReadAccess.sh

#!/bin/sh
## These commands gives the specified group full administrative access to QM
## 
## Usage:
## grantReadAccess.sh <QM Name> <Group>
## 
## <QM Name> : Name of the queue manager for which admin access is required
## <Group> : Group to which administrative access is to be granted

if [ $# -lt 2 ]
 then
 echo "Incorrect number of arguments supplier"
 echo "Usage: grantReadAccess.sh <QM Name> <Group>"
 exit 1
 else
 
 setmqaut -m $1 -t qmgr -g $2 +connect +inq +dsp
 setmqaut -m $1 -n "**" -t q -g $2 +dsp +browse
 setmqaut -m $1 -n "**" -t topic -g $2 +dsp
 setmqaut -m $1 -n "**" -t channel -g $2 +dsp
 setmqaut -m $1 -n "**" -t process -g $2 +dsp
 setmqaut -m $1 -n "**" -t namelist -g $2 +dsp
 setmqaut -m $1 -n "**" -t authinfo -g $2 +dsp
 setmqaut -m $1 -n "**" -t clntconn -g $2 +dsp
 setmqaut -m $1 -n "**" -t listener -g $2 +dsp
 setmqaut -m $1 -n "**" -t service -g $2 +dsp
 setmqaut -m $1 -n "**" -t comminfo -g $2 +dsp

## The following commands provide administrative access for MQ Explorer.
 setmqaut -m $1 -n SYSTEM.MQEXPLORER.REPLY.MODEL -t q -g $2 +dsp +inq +get
 setmqaut -m $1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -g $2 +dsp +inq +put
fi
  • Grant permission on these files to mqadmin and mqm group as shown below
# chmod 774 grant*.sh
  • Run the script files to create requisite ACL for mqsupp and mqmon groups to QM SECUREQM. The script files takes 2 parameters –> Queue Mangare name and group respectively
# cd /home/mqadmin
# ./grantAdminAccess.sh SECUREQM mqsupp
# ./grantReadAccess.sh SECUREQM mqmon

5. Enabling Client Connection for Non-Privileged User Account

All the below steps are to be executed in the scripting window (using runmqsc) of the queue manager

  • Create and start the listener object to specify the port on which the queue manager is to listen for client connections (if not created already)
DEFINE LISTENER(TCP.LISTENER) TRPTYPE(TCP) +
   CONTROL(QMGR) PORT(1909)
START LISTENER(TCP.LISTENER)
  • Modify the queue manager property to enable CHLAUTH and disable CONNAUTH security features and to specify the location of the SSL key database that is to be used by the QM for SSL Communication, as shown below (if not modified already)
ALTER QMGR CERTLABL('secureqm') +
    SSLKEYR('/home/mqadmin/ssl/secureqm/key') +
    CHLAUTH(ENABLED) CONNAUTH(' ')
  • Create a new Server Connection channel that is to be used for client connection to the queue manager for various purposes. By default block all connections on this channel and hence the MCAUSER attribute of this channel is set to ‘nobody’. We will be overriding this value using the appropriate Channel Authentication record depending on the specific value of client’s SSL DN and Issuer DN.
DEFINE CHANNEL(RMT.ADMIN.SVRCONN) CHLTYPE(SVRCONN) + 
  MCAUSER('nobody') SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)
  • Create a Channel Authentication Rule as Back-stop rule (refer CHLAUTH – the back-stop rule (IBM Developerworks Blog)) to block everyone connecting to the queue manager. The CHLAUTH rule created by default with QM only blocks privileged user account, where as the new rule that we are creating is to block everyone (if not created already)
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) + 
    DESCR('Back-stop rule to block everyone') WARN(NO) ACTION(ADD)
  • Create  a new Channel Authentication Rule to identify the client connection based on their SSL DN and Issuer DN and map it to appropriate access level user account on the server side.
SET CHLAUTH('RMT.ADMIN.SVRCONN') TYPE(SSLPEERMAP) + 
SSLPEER('CN=Yuvaraj C P, OU=Training, OU=MQ Support, O=NA') + 
USERSRC(MAP) MCAUSER('yuvaraj') + 
DESCR('SSL Auth for Administrative user') + 
SSLCERTI('CN=Nebula Intermediate CA, OU=Training, O=Nebula Academy') +
ACTION(ADD)

SET CHLAUTH('RMT.ADMIN.SVRCONN') TYPE(SSLPEERMAP) + 
SSLPEER('CN=Monitoring User 1, OU=Training, OU=MQ Mon, O=NA') + 
USERSRC(MAP) MCAUSER('monusr1') DESCR('SSL Auth for Monitoring user') +
SSLCERTI('CN=Nebula Intermediate CA, OU=Training, O=Nebula Academy') +
ACTION(ADD)
  • Refresh the security using the command
REFRESH SECURITY
REFRESH SECURITY TYPE(SSL)
  • Connect to SECUREQM from MQ Explorer on the client machine.Follow the steps provided in section 5 of Part-1 of this blog series, and using the server-connection channel RMT.ADMIN.SVRCONN. 
    • For Administrative access: Try using the key store yuvaraj.jks in MQ Explorer
    • For Read only access: Try using the key store monusr1.jks in MQ Explorer

Notice the kind the access you get on MQ Explorer in both the cases

  • On successful connection from MQ Explorer, check the channel status on MQ Linux server for the SECUREQM as shown below. Check the SSLPEER, SSLCERTI, SECPROT and MCAUSER attribute values on the channel status output

6. Appedix

7. References

CHLAUTH – the back-stop rule (Application Integration Middleware Support Blog)

CHLAUTH – Allow some privileged admins (Application Integration Middleware Support Blog)

Will be following up this blog to extend the client connectivity  with CONNAUTH security feature too.

For any corrections / suggestions / comments / query please do drop a note to reachnebula@learnibmesb.com (or) reachnebula@gmail.com

Securing Queue Manager for Client Connection: Part 1 – Using SSL

Queue Manager provides various security mechanism – Authorization using OAM, Connection Authentication (introduced in MQ v8), Channel Authentication Records (CHLAUTH introduced in MQ v7.1) and SSL.

Am writing a series of blog for securing a queue manager for client connection by combining all these security mechanisms – SSL, CHLAUTH, CONNAUTH and OAM.

In this first part of blog series, we will focus on securing QM client connection using SSL. Also in this blog, instead of using self-signed certificates for the demonstration, we will use OpenSSL tool to setup internal CA’s and use them for signing the certificates for QM and the clients. This is to demonstrate working with CA signed certificates in real-time environments.

For recreating these steps, pre-required softwares are

  • OpenSSL to setup up internal Root CA and Intermediate CA’s and signing the Certificate requests
  • MQ v8 or later installed on the Server (Linux machine)
  • MQ Explorer installed on client machine (For only MQ Explorer installation use SupportPac MS0T)

1. Setting up Internal Root and Intermediate CA’s using OpenSSL

Reference: https://jamielinux.com/docs/openssl-certificate-authority/introduction.html

To install OpenSSL in RHEL / CentOS,

yum install openssl
Note: This is typically installed on CentOS by default.

Creating Internal Root CA

  • Create the required directories for storing all keys and certificates. Note: The index.txt and serial files act as a flat file database to keep track of signed certificates.
# mkdir /ssl
# mkdir /ssl/ca
# cd /ssl/ca
# mkdir certs crl newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
  • Download and Copy the configuration file for the root CA (RootCAConfig.odt) file from the appendix to /ssl/ca/openssl.cnf
  • Create the private key for the root CA using the command provided below. When prompted for pass phrase, please provide the pass phrase for securing the private key. This pass phrase is required for accessing the private key for signing certificates.
# cd /ssl/ca
# openssl genrsa -aes256 -out private/ca.key.pem 4096
# chmod 400 private/ca.key.pem
  • Create the Root CA certificate using the private key we have just created. Enter the pass phrase for the Root CA’s private key when prompted.

 And then provide the requested information for the certificates at the prompts appropriately.

# cd /ssl/ca
# openssl req -config openssl.cnf -key private/ca.key.pem -new -x509 
-days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem

RootCertificate

  • Verify the Root CA certificate that we had just created
    # openssl x509 -noout -text -in certs/ca.cert.pem

Creating Internal Intermediate CA

  • Create the required directories for storing all keys and certificates..
# cd /ssl/ca
# mkdir intermediate
# cd intermediate
# mkdir certs crl csr newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
# echo 1000 > /ssl/ca/intermediate/crlnumber
  • Download and Copy the configuration file for the Intermediate CA (IntermediateCAConfig.odt) file from the appendix to /ssl/ca/intermediate/openssl.cnf
  • Create the private key for the root CA using the command provided below. When prompted for pass phrase, please provide the pass phrase for securing the private key. This pass phrase is required for accessing the private key for signing certificates.
# cd /ssl/ca
# openssl genrsa -aes256 \
  -out intermediate/private/intermediate.key.pem 4096
# chmod 400 intermediate/private/intermediate.key.pem
  • Create the Intermediate CA’s certificate signing request (CSR). And then provide the requested information for the certificates at the prompts appropriately.
# cd /ssl/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 \
      -key intermediate/private/intermediate.key.pem \
      -out intermediate/csr/intermediate.csr.pem

IntermediateCertRequest

  • Create the Intermediate CA’s certificate signing request (CSR). And then provide the requested information for the certificates at the prompts appropriately.
# cd /ssl/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
      -days 3650 -notext -md sha256 \
      -in intermediate/csr/intermediate.csr.pem \
      -out intermediate/certs/intermediate.cert.pem

IntermediateCertSign

  • Verify the Intermediate CA certificate.
# cd /ssl/ca
# openssl x509 -noout -text \ -in intermediate/certs/intermediate.cert.pem
# openssl verify -CAfile certs/ca.cert.pem \                 intermediate/certs/intermediate.cert.pem

Now that we have set the internal Root and Intermediate CA’s for our purpose, we will start working with QM

2. Generating SSL Certificate for QM – SECUREQM

Pre-requisites: MQ v8 server or above is installed in the linux machine and user account mqadmin (member of mqm group) is setup with home directory as /home/mqadmin

  • Setting up the directory for storing the keys
# cd /home/mqadmin
# mkdir ssl
# mkdir ssl/secureqm
  • Create a key database for the Queue Manager SECUREQM using the following command
# runmqckm -keydb -create -db /home/mqadmin/ssl/secureqm/key.kdb \ 
   -pw admin -type cms -stash
  • Queue Manager and the channel processes require read access on the key database & its related files. Hence, set the permissions on the files *.kdb, *.sth, *.crl, and *.rdb, to read and write for the file owner, and to read for the mqm or client user group (-rw-r—–)
# cd /home/mqadmin/ssl/secureqm
# chmod 640 key.kdb key.rdb key.sth
  • Create Certificate Signing Request (CSR) for the SECUREQM using the following command
# runmqckm -certreq -create -db /home/mqadmin/ssl/secureqm/key.kdb \
  -pw admin -label secureqm -dn "CN=secureqm,O=NA,OU=Training,C=IN" \
  -size 2048 -sig_alg SHA256_WITH_RSA \
  -file /home/mqadmin/ssl/secureqm/secureqm.arm
  • Create the SECUREQM certificate using the Intermediate CA’s private key to sign the queue manager’s CSR as shown below
# openssl ca -config intermediate/openssl.cnf \
-extensions server_cert -days 375 -notext -md sha256 \
-in /home/mqadmin/ssl/secureqm/secureqm.arm \
-out intermediate/certs/secureqm.arm
  • Receive the CA signed certificate into the queue manager’s key database using the following command
# runmqckm -cert -receive \
   -file /ssl/ca/intermediate/certs/secureqm.arm \
   -db /home/mqadmin/ssl/secureqm/key.kdb -pw admin -format ascii

We need to add the Root CA & Intermediate CA’s certificate to the queue manager’s key database for setting up the certificate chain of trust.

  • Covert the Intermediate CA’s certificate from PEM to DER format using the following command
# openssl x509 -outform der -in certs/intermediate.cert.pem \
    -out certs/intermediate.cert.der
  • Covert the Root CA’s certificate from PEM to DER format using the following command
# openssl x509 -outform der -in certs/ca.cert.pem \
    -out certs/ca.cert.der
  • Add the Intermediate & Root CA’s certificate to the queue manager’s key database using the following command
# runmqckm -cert -add -db /home/mqadmin/ssl/secureqm/key.kdb \
   -pw admin -label nebula-intermediate \
   -file /ssl/ca/intermediate/certs/intermediate.cert.der \
   -format ascii
# runmqckm -cert -add -db /home/mqadmin/ssl/secureqm/key.kdb \
   -pw admin -label nebula-root -file /ssl/ca/certs/ca.cert.der \
   -format ascii

3. Generating SSL Certificate for the client (MQ Explorer)

  • Setting up the directory for storing the keys
# cd /home/mqadmin
# mkdir ssl
# mkdir ssl/mqexplorer
  • Create a key database for the MQ Explorer client using the following command
# runmqckm -keydb -create \
   -db /home/mqadmin/ssl/mqexplorer/mqex_key.jks \
   -pw admin -type cms -stash
  • Create Certificate Signing Request (CSR) for the mq explorer client using the following command
# runmqckm -certreq -create \
    -db /home/mqadmin/ssl/mqexplorer/mqex_key.jks \
    -pw admin -type jks -label mqexClient \
    -dn "CN=nebula-mqexplorer,O=NA,OU=Training,C=IN" -size 2048 \
    -sig_alg SHA256_WITH_RSA \
    -file /home/mqadmin/ssl/mqexplorer/mqexClient_csr.arm
  • Sign the mq explorer’s CSR using the Intermediate CA’s private key to generate the certificate for the CSR
# cd /ssl/ca
# openssl ca -config intermediate/openssl.cnf 
   -extensions usr_cert -days 375 -notext -md sha256 
   -in /home/mqadmin/ssl/mqexplorer/mqexClient_csr.arm 
   -out intermediate/certs/mqexClient_cert.arm
  • Receive the Intermediate CA signed certificate into the mq explorer’s key database using the following command
# runmqckm -cert -receive 
   -file /ssl/ca/intermediate/certs/mqexClient_cert.arm
   -db /home/mqadmin/ssl/mqexplorer/mqex_key.jks -pw admin 
   -type jks -format ascii
  • Add the Intermediate & Root CA’s certificate to the queue manager’s key database using the following command
# runmqckm -cert -add -db /home/mqadmin/ssl/mqexplorer/mqex_key.jks \
   -pw admin -label nebula-intermediate \
   -file /ssl/ca/intermediate/certs/intermediate.cert.der -format ascii
# runmqckm -cert -add -db /home/mqadmin/ssl/mqexplorer/mqex_key.jks \
  -pw admin -label nebula-root -file /ssl/ca/certs/ca.cert.der \
  -format ascii
  • FTP the mqexplorer directory under /home/mqadmin/ssl/ to the client machine using suitable ftp client.

Now that we are done with all certificates generation for both Queue Manager and the client, lets proceed with start using this certificates for communication between QM and the MQ Explorer.

For this, we need to enable our QM for remote connection and to use the SSL key database we have created in the earlier steps.

4. Enabling Remote Connectivity for QM and to use SSL

As far as this blog is concerned, we will disable the other security features CHLAUTH and CONNAUTH (for MQ 8) of the QM. We will extend the setup to use CHLAUTH and CONNAUTH in the subsequent parts of this blog series.

  • Create a queue manager SECUREQM for our setup purpose using the command shown below, using the mqadmin user account which is part of mqm group
# crtmqm -u SYSTEM.DEAD.LETTER.QUEUE SECUREQM
  • Start the queue manager using the command shown below
# strmqm SECUREQM
  • Get into the scripting mode of the queue manager using the runmqsc command as shown below
# runmqsc SECUREQM

All the below steps are to be executed in the scripting window of the queue manager

  • Create and start the listener object to specify the port on which the queue manager is to listen for client connections.
DEFINE LISTENER(TCP.LISTENER) TRPTYPE(TCP) +
   CONTROL(QMGR) PORT(1909)
START LISTENER(TCP.LISTENER)
  • Modify the queue manager property to disable CHLAUTH and CONNAUTH security features and to specify the location of the SSL key database that is to be used by the QM for SSL Communication, as shown below
ALTER QMGR CERTLABL('secureqm') +
    SSLKEYR('/home/mqadmin/ssl/secureqm/key') +
    CHLAUTH(DISABLED) CONNAUTH(' ')
  • Create a new Server Connection channel to be used by the clients for secured connectivity to the queue manager as shown below

Note: we have set MCAUSER property of the channel to specify mqadmin user account which is privileged user account as it belongs to mqm group. Hence QM will not check for access rights for any connection coming on this channel. We are setting this for demonstration purpose only and this is not to be followed in real-time situations or production environment. Ideally privileged user account should not be set for MCAUSER attribute of channel 

DEFINE CHANNEL(MQEXP.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('mqadmin') +
   SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)

5. Connecting to SECUREQM from MQ Explorer

Pre-requisite: The mqexplorer directory under /home/mqadmin/ssl/ in the MQ Server is ftp’ed on to the client machine where MQ Explorer is installed.

  • Launch the MQ Explorer on the client machine
  • Right click on the Queue Manager folder in MQ Explorer and select the option “Add Remote Queue Manager”

mqexp_ssl1

  • In the Add Queue Manager wizard, specify the QM name as SECUREQM and with the option Connect directly selected, click Next

mqexp_ssl2

  • Specify the connection details of the queue manager – Host Name / IP Address of MQ Server, Port Number as 1909 (port at which QM listener is created & listening) and Server-Connection channel as MQEXP.SVRCONN, and click Next

mqexp_ssl3

  • In the Specify security exit details wizard, without selecting the option Enable security exit, click Next
  • In the Specify user identification details wizard, without selecting the option Enable user identification, click Next
  • In the Specify SSL certificate key repository details wizard, check the option Enable SSL Key repositories. Browse and select the mqex_key.jks file for the Store name property under Trusted Certificate Store as well as Personal Certificate Store categories. Click Next

mqexp_ssl4

  • In the Specify SSL option wizard, check the Enable SSL option wizard and select SSL CipherSpec property value as TLS_RSA_WITH_AES_256_CBC_SHA256 from the list and click Finish

mqexp_ssl5

  • When prompted for the password to access key database, provide the password as “admin” or whatever used at the time of key database creation and click Ok. Queue Manager SECUREQM should be listed in the MQ Explorer on successful connection

mqexp_ssl5a

  • In the MQ Server, check the channel status MQEXP.SVRCONN from the script window of SECUREQM, using the following command. Check for the attributes SSLPEER (denotes the DN of the client) and SSLCERTI  (denotes the DN of the Certificate Issuer), in the output.
# runmqsc SECUREQM
    DISPLAY CHS(MQEXP.SVRCONN) ALL

mqexp_ssl6

6. Appendix

Hope this helps.

Will be following up this blog to extend the client connectivity using SSL with CHLAUTH and later with CONNAUTH.

For any corrections / suggestions / query please do drop a note to reachnebula@learnibmesb.com (or) reachnebula@gmail.com

Integration Node Administration Security – V9 vs V10

Am writing this blog to provide an overview of working of Integration Node’s Administrative Security in v9 & v10. This blog does not cover detailed steps for implementing administrative security for integration node.

Integration Node’s Administrative Security in IIB v9

As MQ was a required component of IIB run-time in IIB v9, most of the security was implemented using MQ, as I have tried to illustrate in the below figure

IIB9_MQSecurity

To enable / disable administrative security for Integration Node in IIB v9, the command to be used is

mqsichangebroker <Integration Node> -s active / inactive

Integration Node’s Administrative Security in IIB v10

IBM Integration Bus v10, introduced flexibility in security by providing option for using either File or MQ to implement Integration Node security. Also accordingly it has introduced new commands mqsichangeauthmode / mqsireportauthmode & mqsichangefileauth / mqsireportfileauth for the file-based authorization.

Administrative Security using MQ-Based Authorization

Have tried to illustrate both MQ-based and File-based authorization in IIB v10. The below figure illustrates for MQ-based authorization, if Integration Node is associated with a queue manager

IIB10_MQSecurity

To enable  MQ-based administrative security for the Integration Node in IIB v10, the command to be used is

mqsichangeauthmode <Integration Node> -s active -m mq

For MQ-based authorization, access level is controlled using the Authorization queues – 1 for Integration Node (SYSTEM.BROKER.AUTH) & 1 for each Integration Server (SYSTEM.BROKER.AUTH.<IntegrationServer>). Access granted / revoked for system level users / groups using the mq command setmqaut command

Administrative Security using File-Based Authorization

The below figure illustrates file-based authorization in IIB v10, that can be used irrespective of whether Integration Node is associated to a queue manager or not.

IIB10_FileSecurity

To enable  File-based administrative security for the Integration Node in IIB v10, the command to be used is

mqsichangeauthmode <Integration Node> -s active -m file

For file based security, access level is maintained using the file Permissions, located in the path

<MQSI_WORKPATH>/registry/<IntNode>/CurrentVersion/Security/node/<IntNode>/

Below image provides the snapshot of the Permissions file to indicate how file based authorization is maintained by Integration Node

permission

Access is granted / revoked for system level users, who are specified as Roles, using the command mqsichangefileauth

mqsichangefileauth <IntegrationNode> -r <role> -p <permissions>

Kindly refer to the article in IBM developerworks for more information on file-based authorization

http://www.ibm.com/developerworks/websphere/library/techarticles/1603_gedupuri-trs/1603_gedupuri.html

For any corrections / suggestions / query please do drop a note to reachnebula@learnibmesb.com (or) reachnebula@gmail.com

Using Shared Libraries in IIB v10

IBM Integration Bus v10 has introduced many new features. One of the important feature, from my point of view, is the introduction of Shared Library concept.

We all know that WebSphere Message Broker v8 provided new ways of organizing resources in toolkit by introducing

  • Application container, as per the info-center, is a container for all the resources that are required to create a solution.
    • Provides run-time isolation –> resources inside the application are not visible to other resources
    • Used when updates to one group of deployed resources should not affect another group of deployed resources
  • Library container, for organizing resources for re-usability. Can be referenced by applications or services or integration projects.
    • WMB v8 introduced Static library

The behavior of the library container introduced in WMB 8 and used in IIB v9, as per info-center are provided below

StaticLib

Drawback of Library used in WMB 8 / IIB 9: Owing to Application / Service’s run time isolation behavior, we solution developers faced major challenges on deciding whether to organize our solution using Applications / Services or using Integration Projects.When solutions were organized using Applications / Services and the reusable artifact(s), like Common Error Handling framework / logging framework, organized using libraries, each application / services carried copy of library within themselves. As a result, any changes made to these reusable artifact always resulted in need to re-deploy all applications / services.

In that regards, organizing the resources as Integration Projects was better and very much appealing.

But IIB v10 has addressed this concern / problem by introducing Shared Libraries. Now the Applications / Services do not take copy of the Shared Library within themselves. As the Shared Libraries are deployed directly at the Integration Server level.

Advantages of Shared Libraries

  1. Shared Libraries can be added to the BAR file independently of referencing Applications / Services
  2. Deployment of updated Shared Library results in the changes immediately picked up by all referencing applications / services at run-time. Hence no need to redeploy all referencing applications / services
  3. Enables using / referencing to multiple XML or DFDL schema files that declare the same elements and types, by having them stored in separate Shared Libraries

Reference: http://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/bc23067_.htm?lang=en

SharedLib

Shared Library vs Static Library from Toolkit to Run-time

  • In the New Library window, specify the name for the library and selecting the library type as “Shared Library”, click FinishLoggerSL
  • Below Images shows the Shared and Static libraries in the toolkit

StaticVsShared

  • Referencing to Shared Library / Static library from Application is shown belowLibReferences
  • When adding to the BAR file, Shared Libraries are displayed in the BAR Editor separately and have to be selected explicitly for adding to the bar file. This is not the case with Static Library as they are added automatically when application referencing them is added to BAR file.

BAREditor

  • After deployment, you could notice the difference between Shared & Static library. Static library copy will be present within the application container, where as the Shared Library is outside the application container and directly under the Integration Server.

Runtime

Hope this blog provides insight into Shared Library feature of IIB 10.

For any corrections / suggestions / query please do drop a note to reachnebula@learnibmesb.com (or) reachnebula@gmail.com.

 

Authentication Feature of MQ 8 – Part 1

IBM MQ v8 has introduced the feature of Authentication for the first time. So far in all the earlier versions, MQ was only providing Authorization using the underling OS. In this blog, will try to cover how MQ is providing Authentication feature.

Authentication mechanism is provided for Local Connection as well as Client Connection. That is, now as a administrator we do have the option of authenticating applications connecting in Binding as well Client mode. And we also have the option of implementing this authentication using underlying OS account or LDAP.

This blog is divided into 2 parts – First part will focus on implementing Authentication using OS while the Second part will focus on using LDAP

To provide authentication, changes introduced in MQ comprises of following

  • 2 new types of MQ AUTHINFO Objects introduced –> IDPW OS and IDPW LDAP
  • 2 System objects, 1 each for OS and LDAP authentication, is created as part of Queue Manager
  • Queue Manager by default configured to use OS based Authentication CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
  • New property “Connection Authentication (CONNAUTH)” added to Queue Manager properties
  • Feature introduced in Channel Authentication Records to override the Authentication behavior that is specified at Queue Manager level using AUTHINFO object

But, before proceeding to cover about the authentication mechanism introduced in MQ v8, lets take a step back to understand how MQ handled authorization prior to MQ 8. Remember there was no authentication in MQ prior to v8.

For Binding mode

ExistingBindingMode

  1. Application running under user account “User1”, makes API call to the queue manager
  2. To check the access level for the user “User1”, queue manager’s OAM retrieves user properties from the OS
  3. Based on the properties of the user, queue manager’s OAM verifies the authority with the ACL

For Client Mode

ExistingClientMode

 

  1. Application running under user account “User1” on MQ Client machine, makes API call to the remote queue manager on MQ Server machine
  2. The Channel Authentication records on the Queue Manager allows remote access / blocks the access based on the rules configured for the server connection channel used by application. When allowed, the Channel Authentication record applied also dynamically sets the MCAUSER (user account) to be used by queue manager for authorization
  3. To check the access level for the MCAUSER value, queue manager’s OAM retrieves user properties from the OS
  4. Based on the properties of the user, queue manager’s OAM verifies the authority with the ACL

Now, lets look at the authentication & authorization mechanism in MQ v8. To enable connection authentication for the QM in MQ 8, new attribute CONNAUTH (Connection Authentication) has been added to queue manager. This attribute points to a name of the AUTHINFO object of types IDPWOS or IDPWLDAP that specifies the authentication requirements.

authinfo

How the ADOPTCTX property of AUTHINFO influences the Queue Manager OAM authorization is illustrated in below table –

adoptctx

Remember, Authorization is an existing functionality that is performed by QM’s OAM. With the introduction of Authentication layer before Authorization, the ADOPTCTX attribute of authentication determines the user id that is be passed onto the Authorization layer, as indicated by the above table.

From the authorization perspective, change introduced in MQ v8 comprises of User-based authorization in Linux / Unix environment. In the earlier versions, authorization was controlled at the group level only in Linux / Unix environment. To enable user-based authorization in Linux / Unix platform, additional attribute “-oa group | user” has been added to the crtmqm command. Default value for the -oa attribute is group.

crtmqm -oa user NEBULAQM

Note: In case, you do not want to use the Authentication feature of MQ 8 and want to disable it, run the following script command (empty space between single quotes)

ALTER QMGR CONNAUTH(‘ ‘)

REFRESH SECURITY

Authentication using OS

IDPWOS

  1. (Client Mode Connection) Application App1 running on Client machine, running under User2 account, makes Connection request to the remote queue manager on MQ Server machine (in client mode) by passing user id as User1 and its password.
  2. (Binding Mode Connection) Application App2 running under User3 account, makes Connection request to the queue manager in binding mode by passing user id as User1 and its password.
  3. (Only for Client connection) The Channel Authentication records on the Queue Manager allows remote access / blocks the access based on the rules configured for the server connection channel used by application. When allowed, the Channel Authentication record applied also dynamically sets the MCAUSER to User3 for use by queue manager for authorization. Also we do have the option of overriding the Connection Authentication properties of the queue manager
  4. Queue Manager authenticates the application connection request by passing the User1 & its password with the corresponding OS account. Once authenticated successfully, it retrieves the User3 account property from the OS for authorization purpose by OAM [Assumption: ADOPTCTX is set to NO in the AUTHINFO object]
  5. Based on the properties of the user, queue manager’s OAM verifies the authority with the ACL

Setting up Queue Manager NEBULAQM for OS based Authentication

Note: Ensure User1 & User3 account is setup on the MQ Server machine. Provide the User1 credential details to the applications to be used for connecting to queue manager

Create NEBULAQM queue manager and start the queue manager. In the script window (runmqsc NEBULAQM) of the queue manager execute the following scripts

DEFINE AUTHINFO(USER.IDPWOS) AUTHTYPE(IDPWOS) CHCKLOCL(OPTIONAL) CHCKCLNT(REQUIRED) ADOPTCTX(NO)

ALTER QMGR CONNAUTH(USER.IDPWOS)

REFRESH SECURITY

SET CHLAUTH(‘*’) TYPE(USERMAP) CLNTUSER(‘User2’) USERSRC(MAP) MCAUSER(‘User3’) CHCKCLNT(REQUIRED) ACTION(ADD)

Hope this blog provides insight into authentication mechanism. Will be following up this with LDAP based authentication shortly.

For any corrections / suggestions / query please do drop a note to reachnebula@learnibmesb.com (or) reachnebula@gmail.com.

 

Pub/Sub in IBM Integration Bus v10 – Using built-in MQTT Server

As I had stated in my previous post, from IBM Integration Bus v10 MQ has been made optional. Those who have worked with earlier version of IIB / WMB might wonder

“What about the pub/sub feature of Integration Node / Broker?”

That’s because, till previous version, i.e. IBM Integration Bus v9, Integration Node was using the MQ’s publish/subscribe engine for all its pub/sub activities, like Event Monitoring etc.

Now with the change in the architecture from v10, Integration Node now comes with built-in MQTT broker thus allowing to use MQTT lightweight publish/subscribe messaging protocol. You could also choose to configure Integration Node to either use an external MQTT server or MQ’s queue manager as pub/sub broker as  an alternative to default built-in MQTT server.

The built-in MQTT server is enabled by default for the Integration Node with the default port as 11883. The MQTTServer gets started automatically along with the Integration Node and also can be shared / used across multiple Integration Nodes.

To view the status of the MQTT server of an Integration Node you could use the following command

mqsireportproperties -b pubsub -o MQTTServer -n enabled

To view the port of the MQTT server of an Integration Node you could use the following command

mqsireportproperties -b pubsub -o MQTTServer -n port

Am going to focus on Event Monitoring, esp. Business Events on this blog to illustrate using built-in MQTT server in IIB v10 integration node SNABRK10.

The IIB Events can be broadly classified as shown below

IBM Integration Bus Events Classification

IBM Integration Bus Events Classification

Of the above 3 classification, if MQ is not installed, Integration node will publish both Operational & Admin events to the built-in MQTT broker by default. Business Events publication to built-in MQTT server is not enabled by default and hence has to be enabled using the following command

mqsichangeproperties SNABRK10 -b pubsub -o BusinessEvents/MQTT -n enabled -v true

To illustrate how to change the port of built-in MQTT server we will configure the Integration Node SNABRK10 to use the port 12885. To change the port use the following command

mqsichangeproperties SNABRK10 -b pubsub -o MQTTServer -n port -v 12885

Please note, message flow should be configured for emitting monitoring events (business events), which is not in the scope of this blog.

Assuming that the solution / message flow with monitoring enabled is deployed and activated, the message flow will publish the business events now to the built-in MQTT Server on port 12885 on the topic specified below

IBM/IntegrationBus/<IntNode>/Monitoring/<IntServer>/<MsgFlowName>/

To subscribe to these business events, we could then develop message flow using the built-in MQTT nodes MQTTSubcribe node, the configuration of which is shown below

IBM Integration Bus v10 - Using MQTTSubscribe

IBM Integration Bus v10 – Using MQTTSubscribe

Hope this provides overview about using built-in MQTT server of Integration Node in IIB v10. Please let me know your comments or any queries that will help me in refining my blogs and focus on areas of your concerns.

Looking forward to your feedbacks !!!

Installing IBM Integration Bus v10 on Linux

From IIB v10, IBM has removed the dependency of Integration Node / Broker on WebSphere MQ, by making it as optional product. Considering the operational dependency that Integration Node / Broker had on MQ in all its earlier version, I would say this is major architectural change for IIB. By doing so, what has happened is the reduction of number of components required to be installed.

In IIB v9, the number of components that were to be installed comprised of

  • IBM WebSphere MQ
  • IBM Integration Toolkit
  • IBM Integration Bus (Runtime Component)
  • IBM Integration Explorer
  • IE02 – ODBC Extender (not required for Windows though)

With IIB v10, the number of components to be installed has reduced to only 2, thus simplifying the entire process of installation

  • IBM Integration Toolkit
  • IBM Integration Bus (Runtime Component)

Now the installation package of IIB v10 comprises of single exe on windows. And on linux, there are no more installation to be performed but only extraction of the installation package. As part of installation, IE02 (ODBC Extender) also gets installed.

Also on linux, we have now have the option of Single User Installation (to be used only by one user) or as Shared Installation. Options has also been provided to covert the Single User installation to the Shared Installation at later stage too, if need be.

In this blog, I will be illustrating the steps for performing shared installation on Linux. Have used CentOS v7 for this illustration

  • Step 1: Login to the Linux server as root. Create a new directory IBM in the /opt folder.
IIB v10 Linux Installation - Creating IBM folder in /opt

IBM Integration Bus v10 Linux Installation – Creating IBM folder in /opt

  • Place the IIB v10 Linux installation  archive into /opt/IBM folder as shown

    IBM Integration Bus v10 Linux Installation - Place installation file in /opt/IBM directory

    IIB v10 Linux Installation – Place installation file in /opt/IBM directory

  • Extract the installation package using tar command. Use –exclude option to omit IBM Toolkit installation,i.e. only to install IBM Integration Bus runtime component

tar -xzf 10.0.0.0-IIB-LINUX64-DEVELOPER.tar.gz –exclude iib-10.0.0.0/tools

IBM Integration Bus v10 Linux Installation - Extract the package using tar command into /opt/IBM

IBM Integration Bus v10 Linux Installation – Extract the package using tar command into /opt/IBM

  • For shared installation, group mqbrkrs and /var/mqsi folder needs to be created. Run the following command to accept the license as well create the requisite folders and groups

./iib make registry global accept license silently

IBM Integration Bus v10 Linux Installation - Creating shared Installation

IBM Integration Bus v10 Linux Installation – Creating shared Installation

  • The above step creates the group mqbrkrs, if not existing, and the /var/mqsi folder. Verify the same as shown below
IBM Integration Bus v10 Linux Installation - Verifying group mqbrkrs & /var/mqsi creation

IBM Integration Bus v10 Linux Installation – Verifying group mqbrkrs & /var/mqsi creation

IBM Integration Bus v10 Linux Installation - Verifying /var/mqsi creation

IBM Integration Bus v10 Linux Installation – Verifying /var/mqsi creation

  • To verify the installation, navigate to /opt/IBM/iib-10.n.n.n and run the following command
IBM Integration Bus v10 Linux Installation - Verifying Installation - Part 1

IBM Integration Bus v10 Linux Installation – Verifying Installation – Part 1

IBM Integration Bus v10 Linux Installation - Verifying Installation - Part 2

IBM Integration Bus v10 Linux Installation – Verifying Installation – Part 2

This completes the installation of IIB v10 on Linux. Next steps would be to create IIB user account and configure the user profile for running IIB commands. This could be done by editing the .bash_profile file of the user and adding the following statement to it.

. /opt/IBM/iib-10.0.0.0/server/bin/mqsiprofile