Quotes

Thursday, July 20, 2017

Tracing mapping node activity

Do you ever wanted to know what's happening in your mapping node.

This is related to the new mapping node introduced in WMB 8.

The debugger doesn't allowed you (for the moment?) to step into your mapping node. There is a way however to know what the broker is doing. Use the "User trace".

Say that your broker is MB8BRK and the execution group "default" and your flow that has a mapping node is deployed on this execution group.

execute the command:

mqsichangetrace MB8BRK -e default -u -l debug -r

-u state that it is a user trace
-l it is the level
-r is to reset your trace
more info at the infocenter

Send a message through your mapping node. The broker will produce a binary trace.
To read this trace execute the following command:

mqsireadlog MB8BRK -u -e default -o myXMLTrace.xml

This command will produce a xml file from the binary.
To have in a human readable format use the following command:

mqsiformatlog -i myXMLTrace.xml -o myTxtTrace.txt

Working with WMQ Authentication Record


It's not the first time that I have been asked to secure a WMQ Server using the out-of-the-box security feature of WMQ.

WMQ provides from V7.1 enhanced security capabilities with the channel authentication records.

There are a lot of information available out there, I have however figure out that it may be not trivial to understand the principle. 

I found very useful information from very knowledge persons at the following link:
Channel Auth Record by Morag Hudson
WMQ Security deep dive with T.Rob.

I provide here after a short description of what the feature provides and examples to help understanding the principle.

Before beginnin, the channel authentication records have to be enabled  in order to be applied by the queue manager. This is a Queue Manager property.

The security feature

So what does this feature provides?
How to define it?

Channel authentication records (CHLAUT) are defined using the MQ Explorer under the channel topic (same level as client channel) or using the scripting interface. 

The aim of this feature is to allow or block access to someone. It comes from the former BlockIP  MQ support pack. It gives also the ability to map a user provided by the client application to another user.
This setting is made of rules that are defined using channel authentication records.

The principle


A client application use a client channel to connect to a queue manager. On the server a server connection channel is associated to this client channel.
It is possible to define a client authentication record that block any incomming connection from an or a range of IP address at the listener level.
If the connection is allowed, queue manager performs the following based on the CHLAUT defines:
1. resolves a rule to be applied on the connection
2. identifies what channel identity information is used for the rule
3. perform an action on the connection: allow, map a user, block

The resolution of the rule is performed using a channel profile.
The rules that are applied are those having the most specific match only. For example if there are two rules with the match criteria "SYSTEM.*" and "SYSTEM.ADMIN.*, then the SYSTEM.ADMIN.* rule will be applied for a client application using a channel "SYSTEM.ADMIN.SVRCONN". It is possible to further filter the rules to be applied by using IP address when the match criteria was SSL, Client User ID or Remote queue manager.

When the rule has been resolved, the queue manager uses the CHLAUTH definition to identify the identity information from the client connection to be used. 
The identity information can be one of the following:

  • SSL Distinguished Name
  • Client user ID (user Id provided by the clientapplication)
  • Remote queue manager
  • IP Address
A special extra rule is available for blocking a connection: "Final user Id".
This rule is applied after that all other rules have been applied and after that any security Id has been called.
A typical usage of this rule is to block any user that has administration rights.

If the channel profile match multiple rules then the rules that the rule precedence order are provided here after:
  1. SSL DN
  2. Client User ID
  3. Remote queue manager
  4. IP Address
    If the value of the identity information match the value defined in the CHLAUTH definition then the action of the CHLAUTH is executed: the resulting of the rule would be either to map the incoming user to another user, to block the connection or to allow the connection.
    If the rule didn't block the connection, the queue manager checks if there is a special rule "block final user Id". If such rule is resolved, the rule is executed to find out if the resolved user is allowed to connect or not. The resolved user may be the incoming user provided with the connection, a user that would have been maped by a previous rule or modified by any security exit called.

    Examples

    I find out that it is easies to understand the principle with some example.

    Example 1

    Lets take the asumption that the queue manager have the following server connection channel defined:
    • SYSTEM.DEF.SVRCONN
    • SYSTEM.ADMIN.SVRCONN
    And the client application is connecting using the client channel "SYSTEM.DEF.SVRCONN" with the user "userX".

    If the following CHLAUTH is defined
    SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP) ADDRLIST(*) USERSRC(NOACCESS)

    This rule would be applied to all server connection channel beginning with "SYSTEM." that a client application would use. 
    The identity information used by the queue manager to apply this rule is the IP address (type ADDRESSMAP) and the it match all the IP addresses (ADDRLIST=*).
    The action of this rule is to block the connection.

    This means that all client application will be rejected if it tries to connect using a client channel that begins with "SYSTEM." and therefore the application connection using "SYSTEM.DEF.SVRCONN" will be refused.

    Now if an MQ administrator add the following rule
    SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(ADDRESSMAP) ADDRLIST(*) USERSRC(CHANNEL)

    It match the server connection channnel "SYSTEM.DEF.SVRCONN".
    As the client application is using this channel, this rule will overwrite the first one for this connection because it is a more specific matching than "SYSTEM.*".
    The rule is using the IP address identity and it match all IP addressses (all client connection with this channel name). 
    The action is telling use the channel user as final user.
    The result will be that the connection will be allowed and the user provided by the client application will be used to get the queue manager authorization.

    Now if the following CHLAUT is defined:
    SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(USERMAP) CLNTUSER(userX) USERSRC(userY)

    When the client application connects, the two rules above matches.
    The table provided upper shows that the client userId takes precedence on IP Address, therefore the new rule is executed.
    If the client application is using the userX then the rule would map this user to userY. If this user has no access authorization to the queue manager then the connection would be refused.


    Finally, if the mq adminstrator creates the following CHLAUT:
    SET CHLAUTH(SYSTEM.*) TYPE(BLOCKUSER) USERLIST(*MQADMIN)

    As this rule is the special extra rule that is applied after the other rules or security exit, this rule is executed after those defined above.
    This rule block all user that have MQ administration right. And this rule is applied for all channels that match "SYSTEM.*". Hence if the client application is connecting with a user that has administration right or if the userY (mapped user for userX) has administration rights, the connection will be refused.

    Default Configuration

    From WMQ 7.1, when a new queue manager is created, the following authentication records are created:

    SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(*MQADMIN)
    SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS)
    SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)


    With the first rule, any user that try to connect using a user having mq administration right will be blocked.

    With the second rule, if the user doesn't have administration right, the user will be blocked if it is connecting using a channel that begins with "SYSTEM." other than "SYSTEM.ADMIN.SVRCONN".

    The last rule allows a user to connect to the queue manager using the channel "SYSTEM.ADMIN.SVRCONN" if the user doesn't have the MQ administration right.

    Sharing code/artifacts


    I have for long time looking for a place where I could place implementation that I have made and share with others.

    I have found some good places.

    ---------------------------------------
    https://hub.jazz.net/

    This place is very good and it's free. You can create projects private or not and add your code.
    There is a  plugin for eclipse as well: on eclipse the software update url:
    https://jazz.net/downloads/rational-team-concert/4.0.6/4.0.6/p2

    You can also define tasks, and so forth...

    ---------------------------------------
    https://github.com/

    This is also a very good place.
    A lot of IBM Integration Bus artifacts are stored and will be stored at this place.
    You can create private/public projects.
    There is a plugin available on eclipse as well: 
    http://download.eclipse.org/egit/updates
    You can get more information at
    http://eclipse.org/egit/download/

    ---------------------------------------
    https://gist.github.com/

    If you have very small code to share with others, this is the place to go !
    ---------------------------------------
     I will try to get some time to provide more information on one these places.

    ActiveMQ & IIB with JMS

    In this topic I will give you some hints on how to connect your IBM Integration Bus to a JMS provider ActiveMQ.
    The following link is very useful:
    http://www.ibm.com/developerworks/websphere/library/techarticles/1211_eswarachary/1211_eswarachary.html
    There are however few information concerning the configuration.
    I provided here after some extra informatio.

    Configuration

    Runtime configuration

    In the MQ Explorer, select the "JMSProviders/ActiveMQ" configurable service  of the Integration node you want to use.




     The default_Path refers to the shared class directory of the IBM Integration Node.

     The jars of ActiveMQ have to be placed into a directory.
    I usually place them in a dedicated directory under the homePath of the IIB Node which on windows is "C:\ProgramData\IBM\MQSI".
    You can know the path using following command and look for "Local Work Path":
    mqsiservice INodeName



    Jar file 

    In order to be able to access activeMQ, the integration node needs the JMS provider jar file and place them in a location accessible to the node. I found convenient to copy the activemq-all.jar file only.

    JNDI Bindings
    In order to retrieve the connection factory, the Integration node needs to have a JNDI.
    A default JNDI is provided with ActiveMQ: org.apache.activemq.jndi.ActiveMQInitialContextFactory

    The jndi objects configuration can be found at the following link:
    http://activemq.apache.org/jndi-support.html

    You need to make this configuration file, the jndi.properties file, accessible to the IntegrationNode.
    As explain at the link:
    "
    Once you have the jndi.properties edited and ready, it needs to be accessible to your application. The easiest way is to add jndi.properties to a jar file. When "new InitialContext()" is called, it will scan the resources and find the file.
     "
    So place the file in a jar file - I just created a zip file, placed the property file in it and renamed the extension to "jar" - and place the jar file in the directory where you put the activemq jars.

    In my configuration I have:




    And in this directory I have the activemq.jar as well as another jar that contains my file "jndi.properties".

    The content of my jndi.properties is:

    java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
    java.naming.provider.url=vm://localhost
    connectionFactoryNames=connectionFactory, queueConnectionFactory, topicConnectionFactory
    queue.jmsINQ=IN.Q
    queue.jmsOUTQ=OUT.Q

    There is a default connection factory "connectionfactory" and two queues.
    The jndi name for the queue IN.Q defined on ActiveMQ is "queue.jmsINQ". The queue is accessed from the node using the alias name "jmsINQ" (without queue).

    IIB Node configuration

    Node configuration

    The JMS Provider name on the JMSInput node is using a configurable service.
    If the corresponding runtime configurable service property is not changed (let the defaulr), the property on the node will be used.
    If you change the default property value on the conf. service then this property will be used.


    Here is the configuration of my input node:

     

    The connection factory "connectionfactory" is the one by default and defined in the jndi.properties.
    And in the "basic" tab of the node, I put the alias name defined in the jndi properties file: jmsINQ for the input.



    That's it !!

    Testing

    If you go on active MQ -> admin -> connections
    you will see your connection.
    Message can be send from ActiveMQ using the "send" tab.