Ability to Block Concurrent Sessions of All Users

This email from Barış Taş at Isbank contains additional detail related to this entry:
From: Barış Taş 
Sent: Monday, December 9, 2024 8:11 PM
Subject: RE: Blocking Concurrent Sessions in a Clustered Environment

Hi everyone,

Thank you all for your time. I will try to summarize the history of this requirement, so that everyone is on the same page. The need is simple but the solution is not: we need to block concurrent sessions of any external user, and this should be completed by the end of the year.

First things first, as I have expressed in the meeting, this need arises from legal obligations so there is no chance of getting around it. Article 3 of the Regulation on Information Systems and Electronic Banking Services of Banks defines open banking as “an electronic distribution channel through which customers or parties acting for and on behalf of customers may execute banking transactions or may instruct the bank for execution of banking transactions through remote access to financial services offered by bank via such methods as API, web service, file transfer protocol, etc”. Article 11 of the same regulation mandates the following: “Unless the information security supervisor gives approval for use of the same user account by more than one user or for opening of different sessions by a user at the same time, if and when it is attempted to open more than one session for the same user at the same time, it is by no means permitted, and the user is warned thereabout.”

At first, we thought that since this should be treated as a security feature and it is much better to block the concurrent sessions at DMZ before it reaches to B2B Integrator, we have explored ways to achieve this on SSP or, secondarily on SEAS. We have been informed that it is possible to define Maximum Session as 1 on SSP adapter however it is a standalone configuration, not applied to other engines. In other words, even though Maximum Sessions is set to 1, it is possible that the same user makes four different connections and the load balancer routes the four different connection attempts to four different SSP engines. Please note that we have four nodes of each SSP, SEAS and B2B Integrator in Production. This inconvenience can be overcome with a persistence or sticky session definition on the load balancer, to ensure that all requests coming from the same IP address are routed to the same SSP engine, however we suspect that this would lead to serious performance issues and uneven load balancing between the members of the cluster. Apart from the load balancer solution, we have been told that there is no way of achieving this at SSP or SEAS level. That is when we started to think about dealing with this requirement on B2B Integrator level.

We have raised a PMR to the support team and discovered that there is a Maximum Concurrent Connections feature under Bandwidth Limiting Policy. Setting Maximum Concurrent Connections to 1 indeed settles the matter- this has been tested by us and it is working, however it requires a necessity of adding the newly created customers, which happens to be a lot, manually to Adapter Policy. Since this cannot be maintained manually, we offered that if it possible to add/select a new user to an existing policy by calling a service inside a business process, we can alter our custom user creation business processes so that newly created user is automatically added to the policy just after it is created. We can share the custom business processes and templates that are responsible to create users, if desired.

As suggested in the meeting, having an option to make it selected for all future users could be very useful, but that would be a very long process, initiated by an RFE, developed and tested by the labs, followed by an upgrade process, etc. We are more than happy to hear or discuss any option that would accomplish this requirement in a short span of time. Nevertheless, we will submit an RFE as suggested.

In my opinion, updating the policy automatically via our custom business processes is the best option for now but it needs clarification from IBM whether it can be done or not. I noticed that there is a table called as POLICY_BANDWIDTH_LIMITING in the database and it contains all of the information regarding the policy, except usernames. I suppose, usernames are stored as blob objects in the database and there might be no possibility to update it using SQL, but this still needs to be confirmed by IBM.

Regards,

Barış.