Identity and Access Management

• Identity Lifecycle Management: Manages the digital identity of all entities (users, systems, applications), including their creation, provisioning, maintenance, and decommissioning.
• Authentication: Verifies the identity of an entity attempting to access the system — passwords, certificates, protocols.
• Authorisation: Controls what actions an authenticated identity is permitted to perform on specific resources, based on assigned roles and policies.
• Access Control Enforcement: Technically enforces authorisation decisions across the ecosystem, ensuring access rights are adhered to during operation. See RBAC for how the role and permission model fits together.

The IAM subsystem operates across two primary phases:

• Configuration Phase: The definition and registration of identities, their roles, and their authorised access rights.
• Operation Phase: The real-time execution of identification, authentication, and access control checks based on the configured policies.

In essence, IAM centralises the policy framework and technical mechanisms that secure the system by guaranteeing the principle of least privilege: the right access for the right entity to the right resource.

These terms name the stages that take ORE Studio from an empty database to a tenant that people use. Every client (ores.web, ores.shell, ores.qt) uses the same terms and runs the same server-side operation for each stage.

• System bootstrap: the system goes from an empty database to a usable state. It creates the system admin only. The system admin then provisions every tenant, the first one included. While system bootstrap is not complete, the system is in bootstrap mode and nobody can log in. "System bootstrap" never means service startup. For service startup, see Service Bootstrap Phases.
• Provision: create an entity with the structure it needs to be usable. A provisioned tenant has its admin, its reference data and its parties. A provisioned party is active, onboarded and linked to the accounts that use it. Provisioning runs on the server, and it uses internal actor impersonation to act as each party.
• Onboard: a person's first use of a tenant or party that exists already. Onboarding sets what the person needs to start work. It does not create the tenant.
• Account-party association: an account works in a party when it is associated with it. The association controls which parties the account can act for: at sign-in, an account that works in more than one party chooses one, and it can switch between them later. Provisioning a party associates the accounts chosen for it.
• Journey: an ordered definition of steps that takes a person through workflows and their own actions (sign-in, onboarding) in order. The journeys are first run, new tenant and new party. A journey is a definition, not a server-side object: its progress is kept as a workflow instance in ores.workflow, so any client can resume it where it stopped. See Journey execution.
• Seed profile: the data set that provisioning gives a new tenant. The profile selects where the parties come from and which bundles are published. The profiles are:
  • Empty operational: a production tenant. It gets the base reference data, a counterparty set and its own parties from a GLEIF root LEI. It gets no test data.
  • ACME demo: the Acme Corporation holding group, with its parties, business units, books, staff and market data. All test data lives in this profile.

• Identity and Access — the structure note that orders this cluster, and where to read this page in it.
• ores.iam.core — domain types and business logic.
• Role-Based Access Control — the role/permission model that backs authorisation.