In Webapps, introduce time to live to update/remove authentications

[tasso94]

Acceptance Criteria (Required on creation)

• By default, cacheTimeToLive is configured in all distros to five minutes.
• Next validation time is set on initial authentication creation (login).
• Authentication is updated/removed whenever TTL expires, and the next validation time is set
• Multiple parallel requests are synchronized on a HTTP session mutex
• Legacy behavior can be restored when removing the init parameter configuration or leaving it empty (<param-value/>)
• When configured to 0, caching is disabled.
• Recreating the cache not only checks if the user still exists but also refreshes the groupIds, tenantIds, and app authorizations; this prevents, for instance, permissions being restricted for a user that is no longer part of the camunda-admin group.
• Config value is...
  • trimmed.
  • must not be negative.
  • configurable in Spring Boot/Run.

Hints

Links

Breakdown

• [x] https://github.com/camunda/camunda-bpm-platform/pull/3147
• [x] https://github.com/camunda/camunda-bpm-platform-ee/pull/773

[tasso94]

Decisions

• Five minutes as a TTL default is a good compromise between not logging out unauthorized users at all and introducing an unexpected load peak because each user session leads to multiple additional queries; if this doesn't satisfy our users, they can change it to a smaller value or zero
• I only added an integration test for Spring Boot since adjusting the web app integration test suite to test the new behavior would be a higher effort; however, we should test the new behavior on all application servers manually; I'll ask our QA Engineer to do this in the course of the Dev2QA handover summary
• The parent ticket only has the requirement to check if the user still exists; I broadened the implementation scope to cover all information relevant for creating an authorization; otherwise, there are similar problems with group/tenant memberships and app access
• I added an optimization that adds the validation time already on login to avoid updating the cache immediately after creation
• Usually, iterating over a list and removing elements is not allowed and results in a ConcurrentModificationException
  • However, in the case of AuthenticationUtil#updateCache, we loop over a copy of the Map<String, UserAuthentication> authentications values; the elements are removed from the map, not from the list
• The new implementation itself doesn't need to send an HTTP error in case there is no authentication for the HTTP session left; the SecurityFilter takes care of this (see EngineRequestAuthorizer and SecurityFilter#sendUnauthorized)

[yanavasileva]

👍 Review of backport is done.