Skip to main content

From catalog to composition: how Ireti onboards applications

· 4 min read
Ireti Engineering
Ireti Engineering
Product and platform engineering

An application is not ready for customers merely because it has an OAuth client. It must be known to the platform, approved for distribution, adopted by a tenant, provisioned against the correct resources, and authorized at launch.

Ireti Platform treats those as distinct stages. That separation lets Arrowflow applications and future partner products share one operating model without sharing databases, credentials, or product authority.

Three authorities, never collapsed​

The lifecycle depends on three independent authorities:

  • Ireti Identity authenticates people and applications and manages OAuth protocol configuration.
  • Ireti Platform owns the catalog, approval, tenant adoption, workspaces, seats, entitlements, launch context, and platform audit.
  • Each product owns its domain records, runtime, local authorization, and product audit.

A Keycloak client is therefore not a catalog application. The client knows redirect URIs, scopes, audiences, and credentials. It does not define pricing, visibility, support status, tenant activation, workspace provisioning, or launch readiness.

Likewise, a catalog entry is not an OAuth credential. It describes a product and its platform contract without taking ownership of authentication secrets.

The lifecycle in three movements​

1. Supply: register and approve an application​

A first-party team or approved provider submits an application definition with:

  • stable application identity;
  • presentation metadata;
  • launch mode;
  • provisioning contract;
  • declared roles and permissions;
  • entitlement and seat requirements;
  • support and release information; and
  • provider ownership.

Registration begins in a pending state. A platform operator reviews the definition, approves or rejects it, and assigns an appropriate release stage. Presentation metadata cannot grant approval or access.

2. Demand: a tenant adopts the application​

A tenant administrator discovers an approved application and explicitly adds it to a workspace. Adoption may involve a plan, subscription, entitlement, or seat capacity, but those facts remain independent.

Activation does not silently create user access. The tenant still decides which members receive seats or roles. A user who can see a marketplace card does not automatically have permission to launch the application.

3. Provisioning: establish product readiness​

Provisioning creates or connects the product-owned resource for the exact organization and workspace. The adapter accepts stable platform identifiers and approved release context, then returns an opaque product resource reference and canonical launch destination.

The platform does not store the product's domain records. The product does not write platform authorization. Each side owns its own state and communicates through a bounded, retryable contract.

Provisioning must be independently idempotent because real systems fail between steps. A retry should reconcile the intended result, not duplicate tenants, accounts, or assignments.

Readiness is a conjunction​

An application is launch-ready only when all applicable conditions agree:

approved catalog definition
AND active tenant adoption
AND ready product binding
AND current entitlement
AND required seat or role
AND current launch decision

A hostname or workspace URL is a selector, never authorization evidence. The product must authenticate the principal and validate the exact organization, workspace, application, and access state.

Composition should use capabilities, not database joins​

Once applications share identity and workspace context, it is tempting to connect them directly. That creates pairwise integrations, duplicated policy, and brittle data coupling.

Ireti instead treats applications as capability providers. A product publishes a bounded contract, and another product consumes it through the platform's approved integration path. The provider remains authoritative for its data and operations.

For example, a customer conversation could produce a meeting event. Notes may prepare a summary, CRM may update a relationship record, and another product may trigger a workflow. The applications do not need mutual database access. They need a stable event, an entity reference, and explicit permission.

This turns composition into a hub:

Product event or capability
        |
        v
Ireti integration boundary
        |
        +--> authorized consumer A
        +--> authorized consumer B
        +--> auditable workflow

Adding another product does not require every existing product to learn a new private API.

Why the separation matters​

The model gives operators one consistent lifecycle while preserving product autonomy:

  • identity registration cannot publish an application;
  • catalog approval cannot activate it for a tenant;
  • tenant activation cannot grant a user access;
  • a seat cannot invent product permissions;
  • provisioning cannot rewrite platform authorization;
  • an integration event cannot bypass the provider's domain rules.

That discipline makes onboarding repeatable and composition scalable. Teams build products, connect them through stable contracts, and reuse the same identity, workspace, access, billing, and audit foundation.