Security hardening of IBM App Connect Enterprise admin UI using LDAP - Using node.conf.yaml or server.conf.yaml

Published on July 6, 2020
Co-author - Martin Evans

Introduction

When setting up authentication and authorization for the IBM ACE Web User Interface (WebUI) there is a need to make changes to the integration node or independent integration server configuration YAML files.

Note: This cannot be applied to the Integration controlled integration servers.

In this article we will explore what the stanzas represent, how they tie in with LDAP and how to configure for a successful setup which should initially be completed in a test system - not a live system.

Note: The WebUI uses the APIs provided by the ACE REST Administrator interface and is setup using the ACE REST admin settings, as such we will refer to both as the REST Admin throughout.

REST Admin Setup

Configuration changes described in this article will be made using the overrides file of either the integration node or the independent integration server as shown in Table 1 – ACE Configuration YAML Location. We recommend this as the overrides always takes precedence so making changes here provides consistency and a single point of reference for any administrators. Table 1 – ACE Configuration YAML Location

To initiate the REST admin listener a port needs to be set in the configuration yaml. At this point there will be no authorization or authentication setup so both the ‘authorizationEnabled’ and ‘basicAuth’ should be set to ‘false’. Figure 1 - Simple REST Admin

To make these changes and test the setup perform the following steps:

1. Login to the ACE server as an ace administration user with all relevant privileged access
2. Create an ACE integration node or independent integration server
   Integration Node:
   mqsicreatebroker MYNODE
   mqsicreateexecutiongroup MYNODE -e MYSERVER
   Or independent Integration Server:
   Integration Server: mqsicreateworkdir /aceworkdir/myserver
3. Edit the configuration overrides YAML as in Figure 1 – Simple REST Admin
   e.g. vi ${IntegationNodeConfigYAMLLocation}
   Table 1 – ACE Configuration YAML Location
4. Restart the node/server
   Integration Node:
   mqsistop MYNODE
   mqsistart MYNODE
   Integration Server: IntegrationServer –work-dir /aceworkdir
5. Navigate to the REST Admin webui endpoint
   http://hostname:1024
6. It will be possible to access the following view without a username, password or any identification.

Figure 2 - Integration Node REST Admin view  Figure 3 - Independent Integration Server REST Admin view

LDAP Setup

This article will not go into detail on the configuration and setup of specific LDAP implementations e.g. Active Directory (AD), Apache, etc. but instead will discuss the expected host, groups, users and attributes required to be setup by the LDAP administrator.

The LDAP server’s hostname for this example will be: mycompany.co.uk

Figure 4 - LDAP Server Hierarchy

In this example we will use an LDAP Bind DN user and password, this is important as some LDAP providers do not support anonymous binding which means a valid user and password must be specified to query the LDAP system.

IBM ACE will drive queries to the LDAP server using the LDAP BindDN user ‘aceldapadmin’. This user is permitted to query the LDAP server in order to determine whether to accept or reject specific users or groups for authentication or authorisation to the IBM ACE objects e.g. the integration node or specific integration servers will provide a Bind DN and Bind Password which drives the user the permissions to connect and search the LDAP server for authentication and authorization purposes.
The user will be called ‘aceldapadmin’.

Figure 5 - ACE connecting to LDAP

LDAP Users

In this example, users will be sorted into an Integration Staff organization each with unique attributes values. A common method for sorting users includes the user identification (uid), Distinguished Name (dn) and sAMAccountName attribute names.

In Active Directory the classic attribute sAMAccountname can be used however the attribute name can be any free-form string. The sAMAccountname has windows constraints for working with the Windows Operating System (https://docs.microsoft.com/en-us/windows/win32/adschema/a-samaccountname)

For ACE system integrating with MQ systems using the same LDAP systems, the Windows Operating System constraints on sAMAccountname will likely be compatible with an IBM MQ short user which needs to be less than 12 characters.

Figure 6 - LDAP User Hierarchy

Each user is searchable within the LDAP Directory with unique distinguished names (DN) which can be filtered based on user attributes e.g. ‘sAMAccountname’ and ‘uid’.

User DNs
DN=cn=Aiden Gallagher,ou=Integration Staff,dc=mycompany,dc=co,dc=uk
DN=cn=Martin Evans,ou=Integration Staff,dc=mycompany,dc=co,dc=uk
DN=cn=Jane Bloggs,ou=Integration Staff,dc=mycompany,dc=co,dc=uk

Filter based on the uid at the LDAP location ‘ou=Integration Staff,dc=mycompany,dc=co,dc=uk’ will return user who matches the input.
e.g. jbloggs => DN=cn=Jane Bloggs,ou=Integration Staff,dc=mycompany,dc=co,dc=uk

Filter based on the sAMAccountname
e.g. 002 => DN=cn=Martin Evans,ou=Integration Staff,dc=mycompany,dc=co,dc=uk

LDAP Groups

Three groups will be needed in an Integration Groups organization. The groups can have any names, but the following have been described for this example. Table 2 - LDAP Groups for use with ACE


  Figure 7 - LDAP Group Hierarchy

Each LDAP implementation varies, for example, you might not be able to search a group for distinguished name, or it might only support memberOf. During our investgation using Active Directory, we found filtering using user DN on a group returns without a match because Active Directory does not allow you to search a group using a distinguished name.

In this example we have added the previously defined users to the Groups as members, with a group ‘member’ attribute and a user ‘memberOf’ attribute as seen in Figure 8 – LDAP User mappings to LDAP Groups.

Each group has an individual distinguished name:
DN=cn=aceadmin,ou=Integration Groups,dc=mycompany,dc=co,dc=uk
DN=cn=aceview,ou=Integration Groups,dc=mycompany,dc=co,dc=uk
DN=cn=jenkins,ou=Integration Groups,dc=mycompany,dc=co,dc=uk

LDAP Users added to LDAP Groups

Each user will be added to one of the groups to allow the ability to test the permissions assigned to each LDAP Group Figure 8 - LDAP User mappings to LDAP Groups

With this setup, the configuration YAML can be updated to reflect the groups and the permissions wanted for each.

Connecting to the LDAP Server

Authentication

Authentication of users means to check that a user is valid in a trusted location – such as an LDAP server. If the user exists, they will be given access to the REST Admin. To authenticate users against the LDAP server the following settings need to be set: basicAuth, port, ldapURL, ldapBindDn, ldapBindPassword – Authorization will be shown later.

Setting basicAuth to ‘true’ means ACE will check the username and password inserted into the WebUI for associated LDAP users for the set filter search defined in the LDAP URL setting. The ldapBindDN will be the name of the LDAP User (ldapaceadmin) which is permitted by the LDAP server to conduct searches and the ldapBindPassword is the associated password. The method for setting the ldapBindDN and ldapBindPassword are described later.

Note: Anonymous Bind is not supported in some systems (https://ldap.com/the-ldap-bind-operation/)

This is performed by editing the configuration YAML (Table 1 – ACE Configuration YAML Location) and restarting the integration node or independent integration server with the following information:

Figure 9 – ACE settings for LDAP Authentication

The ldapUrl that is set needs specific information of where to look in the LDAP server for the user.

 Figure 10 - LDAP URL Setting

In order to connect the ACE server interacts with the LDAP server in specific flow:

1. ACE server presents an LDAP bindDN and bindPassword to the LDAP server
2. The LDAP server verifies that user has permissions to perform searches
3. The search and validation is made to the LDAP Server with the ‘username’ and ‘password’ input into the WebUI.
4. The search verifies whether the user exists, and the password is correct for the specified and found user. From the example above, this searches the ‘Integration staff’ layer of the Hierarchy and below based on the username from the UI being the ‘sAMAccountname’
5. The LDAP server then responds to ACE with success that the username and password was correct or with a failure error.

Figure 11 – ACE to LDAP Flow Diagram

Once the user has successfully authenticated, they are granted access to the REST Admin web user interface and will then go through the authorization stage.

To set the LDAP BindDN and LDAP BindPassword you can run an ACE command on the ACE server itself using ‘mqsisetdbparms’. This will set a reference to the ‘aceldapadmin’ user and its password without requiring either to be stored in plain text in the configuration YAML.

To make these changes and test the setup perform the following steps:

1. Login to the ACE server as an aceadmin user
2. Set the ldap mqsisetdbparms permissions:
   Integration Node:
   mqsisetdbparms MYNODE -n ldap::myldapserver -u aceldapadmin -p
   aceldapadminpasswd
   Integration Server:
   mqsisetdbparms -w /aceworkdir/thisserver -n ldap::myldapserver -u aceldapadmin -p aceldapadminpasswd
   Note: The ‘ldap’ reference name can be any free text, we have used the name of the ldap server ‘myldapserver’ which is good practice.
3. This accessible credential can be seen then by running ‘mqsireportdbparms’
   Integration Node:
   mqsireportdbparms MYNOODE -n *
   Integration Server:
   mqsireportdbparms -w /aceworkdir/thisserver -n *

Authorization

Authorization checks that the user is permitted to perform actions on the integration node, the integration server or access to the required data. To authorize users against the LDAP server the following settings need to be set: authorizationMode, authorizationEnabled and ldapAuthorizeUrl.

authorizationMode set to ‘ldap’ tells ACE to perform an LDAP search for group authorization, authorizationEnabled set to ‘true’ means authorization has to be performed and the ldapAuthorizeUrl tells ACE how to find the groups and roles on the LDAP server.

This is performed by editing the configuration YAML and restarting the integration node or independent integration server with the following information:

Figure 12 – ACE Settings for LDAP Authorization

Figure 13 – LDAP Authorization URL Setting

Authorization of the user against the relevant groups requires group alignment in the configuration YAML to permissions in order to provide successful access to the REST Admin Web UI for users in the defined groups.

Aligning LDAP Groups to Permissions

To align LDAP Groups the distinguished name for the group should be placed in the relevant stanza along with the permissions types: ‘all’, ‘read’, ‘write’ and ‘execute’. By adding a ‘+’ the permissions are granted, by adding the ‘-‘ the permissions are explicitly not set.

This is performed by editing the configuration YAML (Table 1 – ACE Configuration YAML Location) and restarting the integration node or independent integration server with the following information:

 Figure 14 - Group DN for Integration Node Figure 15 - Group DN for Independent Integration Server

Note: The settings in the configuration YAML are case sensitive and must match the LDAP Server explicitly e.g.
LDAP Server: ‘CN=aceadmin,OU=Integration Groups,DC=mycompany,DC=co,DC=uk’
ACE Conf YAML: ‘CN=Aceadmin,OU=Integration Groups,DC=MyCompany,DC=co,DC=uk’
Would not match the LDAP server input and would not be able to validate ACE roles to any group.

In the example Figure 16 – WebUI sAMAccountname input to LDAP and group permissions, a user’s sAMAccount name value and password is typed into the WebUI. This input is used to search the LDAP server for the specific user. Based on the ‘memberOf’ attribute for the user returned from the user search, a list of groups will be returned which aligns to the permissions defined in the integration node or integration server.

Figure 16 - WebUI sAMAccountname input to LDAP and group permissions

When Aiden Gallagher’s sAMAccountname is inserted in the ACE REST Admin WebUI (001). This finds the user in the LDAP server and finds all the groups they are a memberOf. The user will be given permissions to the first found group that has permissions in this case the aceadmin group which gives all permissions. They will then be navigated back to the integration node / integration server information.

In Figure 17 - WebUI UID input to LDAP and group permissions, the UID attribute is used to filter the user called ‘mevans’, get the ‘memberOf’ attribute and align the return aceview group to a set of permissions – in this case ‘read+:write-:execute-‘ which allows only read access. Figure 17 - WebUI UID input to LDAP and group permissions

Protecting REST Admin Communications

Hosting the REST Admin on HTTPS endpoint

To host the REST Admin securely with a HTTPS endpoint, the ACE server needs to provide a trusted certificate in a p12 format. This is password protected so requires an mqsisetdbparms to be run as part of the configuration YAML. ‘sslCertificate’ set the location of the p12 file, and ‘sslPassword’ sets the reference from the mqsisetdbparms for the relevant certificate password.

Table 3 – P12 Locations

To set the sslCertificate and sslPassword using ‘mqsisetdbparms’ perform the following steps:

1. Login to the ACE server as an aceadmin user
2. Set the ssl mqsisetdbparms permissions:
   Integration Node:
   mqsisetdbparms MYNODE -n brokerKeystore::myrestadmin -u temp -p p12password
   Integration Server:
   mqsisetdbparms -w /aceworkdir/thisserver -n brokerKeystore:: myrestadmin -u temp -p p12password
3. This accessible credential be seen then by running ‘mqsireportdbparms’
   Integration Node:
   mqsireportdbparms MYNOODE -n *
   Integration Server:
   mqsireportdbparms -w /aceworkdir/thisserver -n *

Protecting Communications to the LDAP Provider

Each of the existing set properties for ‘ldapUrl’ and ‘ldapAuthorizeUrl’ will need to be updated from ‘ldap’ to ‘ldaps’ and the relevant port set for the secure location.

ACE Trusting the LDAP Server

For mutual authentication of the LDAP server a CA certificate signed by a trusted CA that also signs the LDAPs presenting certificate is needed. To ensure the LDAP server must send a certificate ‘requiredClientCert’ must be set to true. To validate the certificate against the CA, the ‘caPath’ must be set as the directory of the CA location. 

Conclusion

By following this article, you should now understand the relationship of the configuration YAML in both an integration node and independent integration server to an LDAP server. You should now know what needs to be set for authentication of users when connecting via the REST Admin WebUI and the authorization of their groups against a list of permitted actions.

#AppConnectEnterprise(ACE)
#ACEV11
#LDAP
#authentication
#authorization
#node.conf.yaml
#server.conf.yaml