Limit the number of concurrent user sessions

[elasticmachine]

Problem statement: Allow admins to define a maximum number of concurrent sessions per Kibana user. This builds on top of previous work, that introduced server side sessions .

Detailed approach: [This document|https://docs.google.com/document/d/1TpgCdz-S687s2XjTyTuJDx7Ig-rju_nnXfiefyt3dok/edit?usp=sharing], For [the MVP|https://docs.google.com/document/d/1TpgCdz-S687s2XjTyTuJDx7Ig-rju_nnXfiefyt3dok/edit#bookmark=id.ditlr5w78trc] see final section.

Justification: Example customer Enhancement Requests:

• [14109|https://github.com/elastic/enhancements/issues/14109]
• [13049|https://github.com/elastic/enhancements/issues/13049]
• [12108|https://github.com/elastic/enhancements/issues/12108]
• [8393|https://github.com/elastic/enhancements/issues/8393]
• [3676|https://github.com/elastic/enhancements/issues/3676]
• [997|https://github.com/elastic/enhancements/issues/997] etc..

In addition NIST compliance ([800-53 AC-10|https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search#/control?version=5.1&number=AC-10])

Release: The MVP is aimed for 8.7

[gayleb]

General info: Restricting the number of concurrent sessions is a technical control mechanism to enforce that certain accounts/access cannot be shared between multiple or too many users.

[jportner]

This appears to be blocked by #17870, Kibana will need to store session info to be able to limit concurrent sessions.

[jordansissel]

given user by role

Is this intended to limit concurrent sessions by role as in Elasticsearch security role (and not a user)? This doesn't map in my head about the stated objective to limit sharing "accounts" (elasticsearch users?).

[gayleb]

@jordansissel - maybe this is helpful?
The information system limits the number of concurrent sessions for each [account and/or account type] to [number].
Supplemental Guidance: Organizations may define the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or a combination. For example, organizations may limit the number of concurrent sessions for system administrators or individuals working in particularly sensitive domains or mission-critical applications. This control addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts.

[arisonl]

@gayleb Am I interpreting it correctly:
Ability to configure the maximum number of:

1. overall concurrent sessions
2. sessions per user
3. sessions per role

And three more questions:

• Is there a timeframe for this feature we should aim for?
• How much of a prio is this and can we approach it in phases, e.g. per user limit first?
• Are there any known differences in the requirements for the mobile vs full/desktop?

cc @mbarretta @derickson @m-adams @skearns64 @agup006

[Michael-Angel-Sec]

+1 Interested in this feature.

These control options are needed to implement DoD Application Server SRG V2R7 V-35070 Requirements. Excerpt:

Check Text: Review the application server product documentation and configuration to determine if the number of concurrent sessions can be limited to the organization-defined number of sessions for all accounts and/or account types.

If a feature to limit the number of concurrent sessions is not available, is not set, or is set to unlimited, this is a finding.

[ES-Takashi]

kibanaへのアクセス制御ができるのか教えてください。
例えば、40アクセスまでを可能として40以上アクセスがあった場合は受け付けないようにする

[azasypkin]

Hi @ES-Takashi ,

kibanaへのアクセス制御ができるのか教えてください。
例えば、40アクセスまでを可能として40以上アクセスがあった場合は受け付けないようにする

Do you mean 40 active sessions in total or 40 active session per user account?

[ES-Takashi]

Hi@azasypkin

Do you mean 40 active sessions in total or 40 active session per user account?
40 active sessionsを意味します。

[azasypkin]

40 active sessionsを意味します。

Sorry, not 100% sure which option of the two you meant, but I assume 40 active sessions in total. If so, then would you mind explaining your use case? The more details, the better, feel free to use Japanese - we'll translate if needed.

What if a single user creates 40 active sessions (in different browser windows or browsers)? Would it mean that no one else will be able to log in? That would be an easy DDoS like attack.

Having said that, at the moment we're planning to support 40 active session per user account or per user role since it gives administrators much more flexibility, but happy to hear about your use case.

[JohnKnoepfle]

Hi @azasypkin,

With the planned approach, will they be able to limit the number to concurrent sessions per user to zero? I.e. I believe they want to configure it so that a given user can only have a single session active at one time.

[azasypkin]

Hi @JohnKnoepfle ,

I believe they want to configure it so that a given user can only have a single session active at one time.

Yes, this certainly will be possible with the proposal we have (at the RFC stage at the moment). Depending on the configuration, the 2nd session will either be forbidden or it will automatically displace the oldest one. The configuration might look something like this:

xpack.security.session.сoncurrentSessions:
  maxSessions: 1
  exceedAction: displace # Or `forbid`
  roles: [superuser] # Optional. If omitted, the limitation will apply to all users

[JohnKnoepfle]

HI @azasypkin,

Thank you for the quick reply! That sounds like exactly what they are looking for. They are asking for a status update so I will just let them know engineering is actively working on it and it is in the RFC stage.

[azasypkin]

We're planning to start working on this functionality in the upcoming weeks. The initial implementation will include only the bare minimum described in the RFC, the rest of the functionality might be added at a later stage once we gather enough feedback for the initial implementation. Here's what we're aiming for in the initial implementation:

• The global concurrent sessions setting that will apply to all providers. There won't be a provider-specific setting yet.
• The configuration will only support per-user/account configuration. There won't be a role-based configuration yet.
• When the concurrent session limit is exceeded, the oldest session will be automatically displaced. The oldest session will be chosen based on the to-be-introduced created_at session field. There won't be a way to prevent login completely yet (e.g. via exceedAction: forbid).

Essentially the configuration we're going to support initially would look like this:

xpack.security.session.сoncurrentSessions:
  maxSessions: 3

Issues to track:

• Extend session index fields mapping with a session creation timestamp #145097
• Introduce a support for the concurrent session limit configuration #145099
• Document a concurrent session limit functionality #145101

[azasypkin]

Closing the issue since the implementation has landed in #147442 and will be available starting from Kibana 8.7.0. The remaining tasks are tracked separately:

• Document a concurrent session limit functionality #145101
• Explain the logout reason to the user when the concurrent session limit is exceeded #149532