Ability to Block Concurrent Sessions of All Users

We want this requirement for external clients, they log in via SSP. Internal users who log in via B2B Integrator should not be affected by the changes to be made, so a global parameter will not be of use to us. I am sharing the detailed explanation I have provided in the past on the subject below again. In this context, if they can guide us on how to apply the methods they have provided below, we can try it out, it was stated in the cases we opened that this was not possible.

”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 B2B 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.”

Thank you for taking the time to provide your ideas to IBM. We truly value our relationship with you and appreciate your willingness to share details about your experience, your recommendations, and ideas.

We have reviewed this request with our technical team and have determined that we may already support the use case you have described in your request.

There are a few workarounds to provide this functionality

• Modify the BP or onboarding process to set a flag to disable concurrent sessions for every new partner being onboarded

• Use an authentication user exit to perform a check and deny additional authentication requests as needed

• Set a global parameter that blocks all concurrent sessions (including for non adapter services)

  • https://www.ibm.com/docs/en/b2b-integrator/6.2.0?topic=guidelines-user-accounts#T77829__title__7

If we have misunderstood your request, please let us know and provide additional details so that we can better understand the requirement. If you have any additional feedback or thoughts in the meantime, or if there is anything else I can do, please do not hesitate to reply to this message to continue the conversation.