Docs
[IAM]

Structure Overview

The IAM structure in PLTFRMS is designed around multi-tenant identity isolation (Realms) combined with a flexible, role-based access control model.

It connects users, applications, and permissions through a layered structure that remains consistent across both internal PLTFRMS usage and customer-managed environments.

Core building blocks

IAM is composed of the following core concepts:

Realms

A Realm is the highest level of isolation in IAM.

It defines a completely separated identity environment containing:

  • Users
  • Groups
  • Roles
  • Clients (applications)
  • Permissions / scopes
  • Configuration and policies

Each customer typically operates within one or more realms.

Organisations

Organisations represent a business or structural context within a realm.

They are used to:

  • Group users and resources
  • Separate business units or clients
  • Define access boundaries within a realm

A realm can contain multiple organisations.

Users

Users represent individual identities within a realm.

They:

  • Belong to one or more organisations
  • Can be part of multiple groups
  • Receive access through roles and permissions
  • Authenticate via OpenID Connect flows

Groups

Groups are logical collections of users.

They are used to:

  • Simplify permission management at scale
  • Assign roles to multiple users at once
  • Structure teams, departments, or external partners

Groups do not directly grant access — they inherit it through roles.

Roles

Roles define what a user or group is allowed to do.

A role:

  • Is assigned to users or groups
  • Contains one or more permissions (scopes)
  • Can be scoped per organisation or realm

Roles are the main bridge between identity and access.

Permissions (Scopes)

Permissions (also referred to as scopes in OAuth2 context) define specific allowed actions.

Examples:

  • invoices.read
  • invoices.write
  • users.manage
  • payments.create

Permissions are:

  • Assigned to roles
  • Evaluated during OAuth2 token validation
  • Enforced at API and service level

Clients (Applications)

Clients represent applications or services that integrate with IAM using OAuth2/OpenID Connect.

They:

  • Authenticate using OAuth2 flows
  • Request scoped access tokens
  • Operate within a specific realm
  • Can act on behalf of users or as service accounts

Clients are the entry point for external and internal integrations.

Access model summary

Access in IAM flows through the following chain:

User → Group → Role → Permission → Resource

or for applications:

Client → OAuth2 Scope → Permission → Resource

Everything is always evaluated within a Realm context and optionally an Organisation context.

Why this structure matters

This model ensures:

  • Strong multi-tenant isolation (via realms)
  • Scalable access control (via groups and roles)
  • Fine-grained security enforcement (via permissions)
  • Standards compatibility (OpenID + OAuth2)
  • Flexibility for both internal and customer use

IAM structure diagram