feature: organization-level marketplace entitlements

[dweidenfeld]

Feature Description

The Showroom is a shared Platform Mesh environment hosting multiple organizations, including external partners.

Membership in an organization must not automatically provide visibility of, or access to, every marketplace integration available in the shared environment.

We need an organization-level allowlist model. A platform administrator must explicitly decide which capabilities each organization may discover and consume. Everything else must remain hidden and inaccessible by default.

The organization is the entitlement boundary. Its configuration applies to all existing and future accounts within that organization.

Proposed Solution

Introduce organization-level marketplace entitlements managed by authorized platform administrators.

A platform administrator can configure, for each organization:

• Which marketplace entries, MSP integrations, and corresponding APIExports are enabled

An enabled integration may consist of multiple underlying APIExports or provider capabilities. The platform should resolve these dependencies so administrators can grant the complete marketplace offering instead of managing internal APIExports individually.

Acceptance Criteria

• Organizations have separate, independently configurable entitlement sets.
• A new organization starts without access to optional marketplace content.
• Only authorized platform administrators can grant or revoke organization entitlements.
• Organization administrators and members cannot enable additional capabilities themselves.
• Entitlements apply to every existing and future account below the organization.
• Organization members only see explicitly enabled marketplace entries.
• Hidden entries cannot be discovered through the marketplace API or other supported discovery interfaces.
• Direct APIBinding creation or capability consumption is denied when the capability is not enabled, even if its APIExport name is known.
• Enabling an integration makes its complete required capability bundle available to the organization.
• Different organizations can receive different marketplace integrations and capability sets.
• The same entitlement rules apply whether users authenticate through static Keycloak users or a configured external OIDC provider.
• Revoking an entitlement prevents new bindings and consumption. The behavior for existing bindings and resources is explicitly defined.
• The effective entitlement set for an organization can be inspected by a platform administrator.
• Authorization is enforced by the backend. Marketplace filtering alone is not considered sufficient.

Scope Boundaries

This feature defines organization-level entitlement semantics and enforcement.

The following related concerns remain separate:

• Platform-administrator role management and the administration UI are covered by backlog #195.
• External OIDC provider configuration is covered by backlog #354.
• Per-account exceptions within an organization are outside the initial scope.
• Billing, quotas, and metering are outside scope.

Alternative Solutions

Extending backlog #195 was considered. That feature focuses primarily on APIExport enablement UI and defining the platform-administrator role. It does not explicitly define the organization as the access boundary or cover the complete marketplace entitlement flow.

Frontend-only marketplace filtering is insufficient because users could still attempt direct API access or create APIBindings when they know the underlying APIExport.

Account-level allowlists are also insufficient because the requirement applies to the complete organization, including accounts created later.

Additional Context

This requirement originated from the organization-access discussion in Platform Mesh issue #192.

The approved APIExport binding access-control ADR provides a possible enforcement mechanism, but this feature describes the required product behavior rather than prescribing the implementation.