User should be logged out when successfully deleting own account

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-3601
Reporter	BOqXk3o What is this name? This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.
Has restricted visibility comments	false

---

Environment (Required on creation)

• All webapp setups

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket)

• When a user is deleted, their related sessions should be destroyed.

Steps to reproduce (Required on creation)

• log in with jonny1
• go to admin -> user -> delete jonny1 account

Observed Behavior (Required on creation)

• After that jonny1 is still able to perform manipulations and keeps logged in.

Expected behavior (Required on creation)

• as soon as the user account is deleted, it should be logged out

Root Cause (Required on prioritization)

• Deleting users and session management are currently decoupled.
• Once a session is active, it is not validated again if the user still exists.

Solution Ideas

• It is not possible to build this in a call-back like fashion, i.e. when the user is deleted, also destroy the session. Reasons:
  • The engine that implements the user deletion API is decoupled from the webapps (e.g. a user can also be deleted on a different cluster node)
  • Identity providers are pluggable, out of the box we support the engine database and LDAP. It's impossible to have a generic callback mechanisms from these providers into Camunda.
• Instead, we can validate if the user still exists whenever they make a request
  • To avoid overload on the identity provider, it should be configurable in the webapps in which intervals the validation is performed
  • If the interval is set to 0, then every request validates the existence of the user. This will provide the maximum safety that the user is logged out as soon as possible after the user is deleted.
  • The solution needs to work concurrently, i.e. if multiple requests are made in parallel for the same user, it should only validate once
  • The default value should be set so that we do not expect a massive performance impact for users
  • The security guide informs how to configure the behavior and what the tradeoffs are when choosing a value

Hints

Links

• https://jira.camunda.com/browse/SEC-203

Breakdown

### Tasks
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/3146
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/3148
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/3165

Dev2QA handover

• [ ] Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment

[alessandrocavalli]

Further use case, slightly different.

• log in with jonny1
• another user, in another session, log in with admin privileges and deletes the user jonny1

After that jonny1 is still able to perform manipulations and keeps logged in.

Expected:

as soon as the user account is deleted, even from another session by another user, it should be logged out

[tasso94]

Dev2QA Handover

• Documentation
  • https://stage.docs.camunda.org/manual/develop/user-guide/security/#authentication-in-the-web-applications
  • https://stage.docs.camunda.org/manual/develop/webapps/shared-options/authentication/#cache
• Environments to test
  • For this feature, unfortunately, we don't have integration test coverage 🙁 – except for Spring Boot.
  • Since this is a security-relevant feature, we must pay attention if the new behavior exists in any application server.
• Changed components: Webapps.
• Check for each application server/runtime to see if the new configuration properties are functional.

[gbetances089]

Tested on 7.19 snapshot for:

• Run
• Tomcat
• Wildfly/JBoss
• Weblogic
• Websphere
• Sprint-Boot

Test Run: https://camunda.testrail.com/index.php?/plans/view/22657

[gbetances089]

Tested also on the Patch release (7.18.6) and the behavior worked as expected.