IBM Integration Bus 10.0.0.19 is now available

IBM Integration Bus has a long history of allowing users to be authenticated when executing administrative actions against an integration node, using settings in an LDAP server. This makes it easy for our users to unify the control of their security credentials across multiple middleware applications, and centralise their policies for things like the style of password characters and the frequency with which identities and passwords are updated. However, looking beyond authentication, until this fix pack, authorization roles have been defined directly within IBM Integration Bus (either using MQ based configuration or file based configuration) rather than using the definition of LDAP groups. Following the extension of App Connect Enterprise to provide LDAP Group Authorization in ACEv11.0.0.6, we have now made similar changes in IIBv10.0.0.19.

To exploit this new IIB feature your LDAP users must belong to one or more LDAP groups, or have one or more LDAP attributes that map to roles in IBM Integration Bus, so that IIB can decide on the appropriate access privileges to provide. Roles in IBM Integration Bus have read, write, or execute permissions for objects in integration nodes. You can configure these authorization roles by setting properties in a new configuration file named ldap.auth.yaml. An example showing the layout of this yaml file is provided in the directory. Another example is shown below:

RestAdminListener:
# ldapAuthorizeUrl: ldap[s]://server[:port]/baseDN[?[attr_name][?[base|one|sub]][?filter_expr]]
  ldapAuthorizeUrl: ldap://ibmexample1:10389/dc=example,dc=com?ou?sub?(uid={{username}})  

Security:
  LdapAuthorizeAttributeToRoleMap:
    businessgroup1: adminRole
    businessgroup2: viewRole

In this example:

• ibmexample1 is the hostname of the LDAP server
• 10389 is the port number of the LDAP server
• dc=example,dc=com is the baseDN (Distinguished name)
• ?ou is the attr-name
• ?sub indicates a subset of the LDAP tree structure is to be searched
• uid={{username}} is the filter expression

If we break this down, this ldapAuthorizeUrl is telling IIB to:

1. Do a sub-tree scoped (‘sub’) LDAP search without SSL (‘ldap://’) on server ibmexample1 listening on port 10389, for objects in the search base dc=example,dc=com matching search filter (uid={{username}}) and return, for every matching object, the value of its ou attribute which we assume to be an LDAP group.
2. If any of the returned values (LDAP groups) case-sensitively string-equals businessgroup1, we shall grant the web user the IIB role adminRole (if it exists), and similarly, if any of the returned values case-sensitively string-equals businessgroup2, we shall grant the web user the IIB role viewRole (if it exists).

To apply this configuration example to your IIB installation, the following settings and commands are required:

• Define the adminRole and viewerRole permissions:

  mqsichangefileauth NODENAME -e SERVERNAME -r adminRole -p read+,write+,execute+
  mqsichangefileauth NODENAME -e SERVERNAME -r viewRole -p read+,write-,execute-
  

• Enable LDAP security:

  mqsichangeauthmode NODENAME -s active -m ldap

• Define the credentials to bind to the LDAP server (where admin123 is the password):

  mqsisetdbparms NODENAME -n ldap::ibmexample1 -u “uid=admin,ou=system” -p admin123

• Define configuration for LDAP authentication. The mqsichangeproperties command specifies the URI for the LDAP server:

  mqsichangeproperties NODENAME -b webadmin -o server -n ldapAuthenticationUri -v \"ldap://localhost:10389/dc=example,dc=com\"

• Define configuration for LDAP authentication. The mqsiwebuseradmin command below specifies a wildcard for all users, so that when a user attempts to log-in to IIB, the identity is passed to LDAP for authentication. Before fix pack 19, all authenticated users would map to the same role (in the example below, this would be the role thisroleisoveridden), but given the other settings for LDAP group authorization this role mapping can now be overidden in fix pack 19:

  mqsiwebuseradmin NODENAME -c -u '*' -x -r thisroleisoveridden

• Define the location of the YAML file (with the content described up above) with the LDAP authorization settings:

  mqsichangeproperties NODENAME -b webadmin -o server -n ldapYamlPath -v "C:\LDAPEXAMPLE\ldap.auth.yaml"

If you wish to try out an example similar to this, and you don’t have an LDAP server to hand, you may wish to install Apache Directory Studio on Windows. Some more detailed instructions for getting this software installed and configured were included in an older blog post from last year. In our example, we have an LDAP server with a handful of users set up to match the configurations discussed above, so for example consider these two entries:

The culmination of these settings is such that when Ben logs in, being a member of businessgroup1, he is assigned adminRole’s complete set of all privileges. In contrast, when Graham logs in, being a member of businessgroup2, he is assigned viewRole’s set of privileges.