Investigations and Designs

Description

Scope:

Karate tests - How can we organize/refactor the existing Karate tests to work with applications, but also still work with the legacy platform?
Sidecars - investigate how to invalidate caches upon logout.
Ability to resume jobs in the event that the node that was handling the job failed (cluster awareness?)
- Spike/Design
  - Refer to the FRM design - it sounds like they do something similar (heartbeats, etc.)
- Implementation - out of scope, handled in a separate feature.

Implement/formalize "upgrade" of applications instead of forcing the operator to disable/enable.
- Spike/Design*
  - Do we need additional endpoints? Parameters in existing endpoints, etc.
  - Ideally we don't need to make any changes on the module side
- Implementation - out of scope, handled in a separate feature.

Analysis of permissionsDesired/optional Interface use
- Includes the use of Optional, multiple interfaces.

Investigation into idle session timeouts
Placeholder for spike/design work related to FedRAMP gap analysis (set aside some time)
Placeholder for unplanned spikes/investigations
Design for setting keycloak realm params based on tenant attributes
Investigate how to configure keycloak password lifecycle policies
Investigate signing key rotation
- Via tenant attributes
- Adjustments on the client side?
- Implementation of mgr-tenants -> keycloak interactions
- Does keycloak have this ability OOTB? If so, how should it be configured?
  - Can we somehow leverage AWS KMS?
- Which components need this information? (is it only Sidecars and Keycloak?)
- How do the components get the latest signing key? How often?
- See https://www.keycloak.org/docs/latest/server_admin/#realm_keys - I think it's relevant
Investigate options for migrating from OKAPI timers on the legacy platform
Revisit platform descriptors
Investigate improvements to impersonation
Sidecars - investigate opportunities for reducing resource consumption
- e.g. replace Kafka with polling/etc.