Spike Overview

EUREKA-602: Spike - Investigate improved capability management in various scenariosIn Refinement

Objective: Identify approaches to improved capability management in various scenarios which mean all defined requirements/criteria.

Background

There are several scenarios where capabilities which were previously defined, are still assigned to users, even though the application which defines them has been disabled. The goal of this spike is to find a solution which fulfils all applicable criteria/requirements.

Problem Statement

Scenario #1 - Splitting Applications / Moving modules between applications

An application (app-original) consisting of a single front-end module and a single backend module is enabled for the central tenant and a member tenant (ECS). Later, that application is split into two applications; app-fe and app-be. When disabling the original application (app-original), we don’t specify purge=true and the capabilities defined by the app-original modules remain in the system. We then enable applications app-be and app-fe for the central tenant. Everything so far is good. The capabilities are updated with the new applicationId and no roles need to be recreated or anything. However, we only want to enable app-be for the member tenant. Doing so leads to the problem where users in the member tenant are still assigned roles which include the app-fe capabilities, even though app-fe is not enabled. The _self endpoint returns these app-fe capabilities/permissions, and stripes shows the app-fe UI components, which is not desirable.

Scenario #2 - Renaming/Replacing permissions

An application (app-foo) consists of one or more modules. The application is enabled for a tenant (ECS or single-tenant). Capabilities are created as usual. Later, developers rename a permissions in one of the module’s descriptors, using the “replaces” property. A new version of the module is released, and a new version of app-foo is released. There are two variants of the rest of this scenario to cover two different entitlement flows…

#2a - using the upgrade operation

When upgrading to the new version of app-foo (via the upgrade operation), the capabilities corresponding to the original permissions are not removed, and new capabilities are created corresponding to the permissions w/ the new names. This eases transition as UI module code which might still refer to the old permission name (e.g. to show/hide a component via IfPermission), will not break, but at some point we probably need to clean these outdated capabilities up.

#2b - explicit disable, followed by explicit enable

The old version of app-foo is explicitly disabled, and the new version of app-foo is explicitly enabled (as opposed to using the upgrade operation like in #2a). During the enable operation, the capabilities corresponding to the original permissions are not removed, and new capabilities are created corresponding to the permissions w/ the new names. This eases transition as UI module code which might still refer to the old permission name (e.g. to show/hide a component via IfPermission), will not break, but at some point we probably need to clean these outdated capabilities up.

Scope

Criteria/Requirements

 Proposed Solutions

Scenario #1 - Splitting Applications / Moving modules between applications

Solution #1 - flag capabilities as disabled

1. Add a new “disabled” boolean property to capability and capabilitySet schemas. This is a system-managed field (read-only)

2. When disabling an application for a tenant, the tenant-entitlement manager publishes kafka messages

3. mod-roles-keycloak consumes these kafka messages and marks all associated capabilities as disabled.

4. The GET /_self endpoint provided by mod-login-keycloak should not return permissions associated with capabilities/capabilitySets which are marked as disabled.

5. Ui-authorization-roles should specify a query when retrieving capabilities/capabilitySets which does not include disabled capabilities/capabilitySets.

6. When enabling an application for a tenant, the tenant-entitlement manager publishes kafka messages

7. mod-roles-keycloak consumes these kafka messages, creates capabilities/capabilitySets as needed, and finds any matching capabilities/capabilitySets which already exist (but are marked disabled), and updates them as needed, including removing the disabled designation.