Identity Migration: Migrate tenant memberships

[joaquinfelici]

User Story (Required on creation)

Tenant memberships can be migrated.

Functional Requirements (Required before implementation)

Technical Requirements (Required before implementation)

Limitations of Scope

Hints

• Also fix error in docs table (Tenants should say Yes and Users should say No).

• Memberships cannot be queries with ID so that we can keep track of them. Because of this, we should consider some solutions to work around this and make a decision. Some ideas:

  • Enhance C7 pivate api to be able to retrieve memberships with ID.
  • Don't keep track of memberships in the migrating table, migrate memberships as part of a group/tenant entity (Consider a group migrated when the group is created in C8 + all memberships for the given group have been created).

Links

Breakdown

Pull Requests

• feat(identity): migrate tenant memberships #991
• docs(migrator): update identity docs for tenant membership migration camunda-docs#7994

Dev2QA handover

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

[joaquinfelici]

Decision making

Problem

C7 doesn't expose a way to query for tenant membership entities (both public and private API).

Option 1: Adapt C7 to retrieve membership entities

Pros:

• Will be aligned with other entities.
• Allow to retry and list skipped memberships (for example because user/group doesn't exist).
• Safer option regarding performance and fault tolerance.

Cons:

• More implementation efforts (requires SQL, private API, pagination, etc). Today there's not even a TenantMembershipQuery api.
• Might be overkill.

Option 2: When migrating tenant, query for users/groups that are members of the tenant.

When migrate a given tenant, migrate memberships as part of the tenant itself. The memberships can be inferred from:

List<User> users = identityService
    .createUserQuery()
    .memberOfTenant(tenantId)
    .list();

List<Group> groups = identityService
    .createGroupQuery()
    .memberOfTenant(tenantId)
    .list();

Pros:

• Smaller implementation effort.

Cons:

• Not aligned with other entities (we wouldn't keep track of memberships to retry them individually) -> Might not such a big deal since in any case C8 won't produce a key for each membership.
• Least safe option regarding performance and fault tolerance.

Decision

Go with Option 2.

Provide this solution which could enough and requires much less implementation effort. Revisit option 1 at a later iteration if user feedback suggests it.

Limitation (to be documented): memberships cannot be retried if they fail to be migrated.