Note that the "termination on the client side" technique was suggested for a java-based client.
If your client were a web page, it might be easier for a malicious user to disable the mechanism.

The idea is that the Data Adapter should manage special items that allow each single client session to subscribe to its own item, so as to receive its own notifications from the Data Adapter. For instance, the item names might be of the general form "<sessionID>_status".
The client should only subscribe to a generic name like "session_status"; then, the Metadata Adapter, in getItems could generate the final name by leveraging session information.
The Data Adapter might manage a single field for all those items (let's call it "allowed") and value it as "Y" or "N", according to your constraints.
A client which found that the "allowed" field has a value of "N" should disconnect.

Consider that the forthcoming 3.6 release of the Server will support a new "destroy session" request, as a milder replacement for the deprecated "kill all user sessions" feature.
So, it will be possible to issue the request from any backend process that knows the active session IDs (by communicating with the various Metadata Adapter instances).
However, the availability of the generic client SDK would be needed, which requires the Presto or Vivace version of the Server.