Tenant users: application-user registry with a provisioning callback, owner invitations and Settings → Users (#7498)

[iliyan-velichkov]

Why

Under TOKEN_GROUPS a tenant's membership lives at the identity provider as groups <tenantId>.<appId>.<role>, and an application can only ask for a new member. Three things were missing:

• A screen. No shell let a tenant owner invite another person.
• A record. Nothing recorded who was invited, by whom, or what became of the request.
• A way back. A provisioning system that grants the group had no way to tell the application the outcome.

Fixes #7498 (which supersedes #7429).

What

Commits 1–6 are one per piece, in the order below. Three review follow-ups sit on top:

• refactor(tenants): requests and their outcomes live on the role rows moved the pending request from the user row onto the role rows. Its result is what the text below describes.
• fix(tenants): address CodeQL findings passes request-derived and configuration values through LogSanitizer before logging them, refuses a null invitation body explicitly, and drops resend's unused body parameter.
• refactor(tenants): application roles are constants; the owner endpoints use @RolesAllowed removed the owner-role and grantable-roles configuration keys. The owner endpoints are now protected like every other service.

1. The users registry and the callback (core-tenants-users, new module)

• DIRIGIBLE_APPLICATION_USERS holds one row per tenant and email: the status (PENDING, INVITED, ASSIGNED, ACTIVE, FAILED), who invited and who last changed each person, and the last sign-in.

• DIRIGIBLE_APPLICATION_USER_ROLES holds one row per user and role for the role's whole life:

  • its state (REQUESTED → GRANTED | FAILED);
  • its latest request (id, requested by and at);
  • granted by and at;
  • the failure text.

  Every request and outcome lands on the row of the role it is about, so different roles can be requested side by side.

• Both are SystemDB tables with an explicit tenant id, and every lookup is scoped by it. Six Liquibase changesets.

• The entities do not extend Auditable. Its auditor stamps a fixed technical name, while who invited or changed a user is a person.

• PUT|GET /services/tenant-provisioning/tenants/{tenantId}/users records INVITED, ASSIGNED or FAILED. It exists exactly when the tenant provisioning API does, behind the same roles and that API's {status, error, message} body. TenantProvisioningRoles is now public so the role constants are shared, not copied.

• The merge rules make a replayed outcome harmless:

  • a success makes the role GRANTED, and a role already granted keeps its first who and when;
  • a status is never lowered (ACTIVE > INVITED > ASSIGNED > PENDING/FAILED), and a person who already signed in becomes ACTIVE;
  • a FAILED for a granted role, or for an older request of that role, is ignored;
  • otherwise it marks the role FAILED, and the user only while no role is granted or still requested.

2. The owner endpoints (/services/security/tenant-users)

• GET /context, GET (list), POST (invite), POST /{id}/roles/{role}/resend. They exist only with DIRIGIBLE_TENANT_USERS_ENABLED.
• A validator refuses to start without TOKEN_GROUPS and a request queue. It warns when invitations would land on the embedded broker.
• The roles are constants, not configuration: ApplicationRoles in core-base, next to Roles, holds OWNER, USER and ALL.
• The endpoints use the standard @RolesAllowed:
  • listing is for Owner, DEVELOPER, ADMINISTRATOR and OPERATOR;
  • invite and resend are for Owner, DEVELOPER and ADMINISTRATOR, so developers and administrators manage users as they do elsewhere.
• A refusal is 403 NOT_A_TENANT_OWNER, in the same shape as the other errors. The default tenant is refused with 409 DEFAULT_TENANT.
• The tenant is always the session's selected tenant, never a request field. Both POSTs accept JSON only (consumes), so a cross-site form post gets 415.
• An invitation records the role as REQUESTED first, then publishes the user.assignment.requested v1 envelope.
  • A role is requested once at a time (409 REQUEST_PENDING), and a granted one is not requested again (409 ROLE_ALREADY_GRANTED).
  • A failed publish is undone and answered 503.
  • Resend reuses the role's message id while it is still REQUESTED.

3. Sign-in tracking

• TenantSelectionManager.selectTenant publishes a TenantEnteredEvent (in core-tenants). That method is the one place the picker and the auto-selection of a user's only tenant go through.
• A listener matches the person by email, stamps the last sign-in, and turns an invited or assigned user ACTIVE. It runs in its own transaction and never throws.

4. A Keycloak test harness

• No browser test could sign in with tenant groups before this.
• KeycloakTestContainer runs one Keycloak per test run and builds its realm through the admin REST API. KeycloakUserInterfaceIntegrationTest boots Dirigible with the keycloak profile under TOKEN_GROUPS against it.
• It needs Docker and runs in the nightly ui shard.

5. Settings → Users in the application shell

• A built-in section rendered from one shared fragment (application-core/shell/views/_tenant-users.html and the tenantUsers store), the tenant chip's pattern.
• It shows the people with their roles (granted, requested or failed, with who and when), status, invited and updated by/at, and last sign-in.
• It has an invite form, and a role requested more than 15 minutes ago with no answer can be sent again.
• Strings are in en-US and bg-BG.
• The Settings footer entry used to require an application SETTING perspective, which also hid the three existing built-ins on an instance without one. It now also opens for this section.

6. The generated application shell mounts the same section, and Settings is now routed in every generated shell. Before this, a model without a SETTING entity had no Settings at all.

Behaviour

Situation	Users section
DIRIGIBLE_TENANT_USERS_ENABLED off	absent (the context endpoint answers 404)
on, caller is an Owner of the selected tenant, a developer or an administrator	offered: list, invite, resend
on, caller is a member without the Owner role	not offered; list and invite answer 403
on, operator in a tenant	may list through the API; the section is not offered
on, default tenant	not offered, and the API answers 409 DEFAULT_TENANT

Tests

• Unit: ApplicationUserServiceTest (every merge rule, plus the per-role invite, resend and undo rules), TenantUserInvitationServiceTest, TenantUsersAccessTest, TenantUsersConfigValidatorTest, TenantUserSignInListenerTest, and two new cases in TenantSelectionManagerTest.
• Integration, HTTP:
  • ApplicationUsersProvisioningApiIT / …DisabledIT
  • TenantUsersIT: a fabricated OIDC owner under TOKEN_GROUPS; the envelope is read off the queue; the 409s, the 403 for a member's list and invite, and the 415 for invite and resend; a second role requested side by side; per-role resend; the callback; sign-in to ACTIVE
  • TenantUsersDisabledIT
  • GeneratedShellTenantUsersIT: both template branches on rendered pages
• Integration, browser (Keycloak): KeycloakTokenGroupsSignInIT, TenantUsersSettingsIT (an owner invites and sees the request pending; a member is not offered the section), TenantUsersSettingsHiddenIT.
• Unchanged and green: HarmoniaContractIT, ShellRuntimeVintageIT, TenantSelectionIT, TenantProvisioningApiIT, TenantWidgetIT, MultitenancyHarmoniaIT and the multitenant-mode ITs.
• When each suite was run:
  • all of the above (66 ITs) passed locally on commits 1–6;
  • after the review commits, the affected ITs were re-run locally and pass (the users API, invitation, disabled, settings browser, Keycloak sign-in, tenant selection, generated-shell, contract and vintage ITs);
  • the PR's CI covers the rest.

mvn install -P integration-tests -pl tests/tests-integrations -D selenide.headless=true \
    -Dit.test="ApplicationUsersProvisioningApiIT,TenantUsersIT,TenantUsersDisabledIT,GeneratedShellTenantUsersIT,KeycloakTokenGroupsSignInIT,TenantUsersSettingsIT,TenantUsersSettingsHiddenIT,HarmoniaContractIT,ShellRuntimeVintageIT"

Not in scope

• Consuming the request and creating the account at the identity provider (the provisioning system's job).
• Removing a member or changing roles.
• A generic header or Settings extension point.
• A browser case on a generated project. The model deployer generates over REST with basic auth, which the keycloak profile switches off.

🤖 Generated with Claude Code