[Feature Request] - Limit how many sessions a user can have PER kasm

[brolifen]

Is your feature request related to a problem? Please describe. Currently you can only set the max amount of kasms a user can open using max_kasms_per_user. But this applies on a global level. There is no way to set this on a kasm level.

Describe the solution you'd like Allowing for a setting to set the max kasms per user on a workspace level would allow more control and less confusion as to how many kasms a user can have open of a particular workspace. This gives you more control as an admin and less cluttering as an end user. Since the setting would be linked to a workspace you can easily create workspaces that allow 1 or more instances to be run for a particular group.

Here's an screenshot example of why this can be useful. You see multiple sessions all to the same server as right now you can start multiple sessions, this can be desired if using different accounts but can also clutter the workspace and use up resources needlessly if you only need one session per user.

EDIT: Added screenshot

[j-travis]

Thank you for the recommendation. Would you be able to give an example of your use case that requires this type of control? It helps us when planning the new features

[brolifen]

Hi justin, thanks for taking the time to answer these really appreciate it.

Our main use case is leveraging Kasm Workspaces to be the only entry point to a customers Active Directory environment for privileged access eliminating insecure VPNs and agents. We typically secure these using one or multiple jump hosts and Kasm will now be used to connect to these jump hosts using AD credentials which the user has been provided through an external PAM solution. The user then comes in on Kasm through an external Idp that knows nothing about the AD environment. Since we cant use the API to provision a Kasm session with credentials linked to it see: https://github.com/kasmtech/workspaces-issues/issues/384 The users are given their privileged AD credentials manually but somewhat securely (we would like to eliminate this) that they then input manually too when they create the Kasm server session.

Because a single user is also associated with a single named AD account there is no use for multiple connections to these jumphosts a session is always one to one. We noticed this during a POC where users cluttered up their workspace and where each new RDP connection just took over the already existing one which caused further confusion and degraded the user experience. The above screenshot also demonstrates this.

Setting a limit on how many sessions a user can have open per particular Kasm gives more control over this behavior, avoids confusion and avoids bumping against any global session limit that were set.

As a bonus, caching the provided credentials during the lifetime of the server session AND/OR being able to set these using the API when you request a Kasm would allow us to offer a killer remote access app. As many Idps offer passwordless auth tech these days which Kasm is agnostic to. If it were possible then when a user logs on they would see sessions waiting for them with prehydrated cached credentials (provisioned externally using the API) offering a true passwordless solution to access a legacy environment which typically is offered only by much more higher end (and expensive) solutions that do everything (like CyberArk). This option would would make credential management within Kasm irrelevant for this use case, all Kasm would know is the session and its credentials that exists within it.

Even without the API option, caching the provided credentials just gives an overal better user experience as "resuming" a session would actually do what it says.

I hope this makes it more clear.