Security Domain Model

The SDK ships a time-aware RBAC engine with optional explainability.

Authorization is defined as:

Authorization = f(App, Actor, Timestamp)

Three inputs, one decision. No hidden state.

The same grant model from the other end: what an administrator sees when they give one partner an ability directly, beside what the partner already inherits.

Core entities

Artifacts — sdk_artifacts

Every UI5 artifact (app, report, card, dashboard, …) is registered with:

• namespace (unique, e.g. com.acme.accounting)
• type — the Core ArtifactType
• version
• expose — whether the artifact takes part in intent-based navigation
• title, description

Each Ability belongs to exactly one Artifact (App).

Abilities — sdk_abilities

• id
• artifact_id
• ability — semantic name
• type — one of Act, See, Access, Read

Unique per (artifact_id, ability, type). Act guards a backend operation, See the visibility of a UI element, Access entry into an artifact (app, card, report, …), and Read an OData entity set.

Roles — sdk_roles

• role — unique semantic identifier
• optional scope — the model a role is held per (see Role Scope)

Role → Ability via sdk_ability_role.

Groups — sdk_groups

• code — unique
• description

Group → Role via sdk_group_role. Group → Ability via sdk_ability_group.

Groups are structural aggregators that combine roles and abilities into a single grantable unit.

Partners — sdk_partners

Represents business actors: users, organizations, teams. Multi-tenant arrangements live here.

Grant tables (time-aware)

All grants are time-bound:

valid_from
valid_until

No nullable timestamps. Defaults are enforced: the current time for valid_from, 9999-12-31 23:59:59 for valid_until.

Table	Direction
sdk_ability_assignments	Partner → Ability (direct grant)
sdk_role_assignments	Partner → Role
sdk_group_assignments	Partner → Group

sdk_role_assignments also carries context_type / context_id: the scope of a role assignment (which customer, which territory). See Role Scope. Ability and group assignments carry no context. Impersonation delegations are stored separately, in the time-bound sdk_delegations table (see Impersonation).

Runtime context

Authorization always evaluates against an explicit context: SdkContext, which implements Core's Ui5ContextInterface. It carries:

• artifact — the current Ui5ArtifactInterface
• tenant — the current TenantInterface (always present)
• actor — the partner whose grants are evaluated
• principal — the authenticated identity (may differ from the actor under impersonation)
• locale
• timestamp — the moment authorization is evaluated

$context->at(): Carbon

Time is part of the runtime reality. There are no internal Carbon::now() calls inside ability contributors — the timestamp comes from the context. This is what makes historical evaluation, time-bound grants, and deterministic tests possible.

Architectural principles

• Time-aware authorization
• Deterministic evaluation
• SQL-first performance
• Explainable security
• No hidden state
• Context-driven evaluation
• All abilities scoped to App
• Single union-based grant resolution
• Snapshot and Explain share the same SQL backbone

For the actual resolution algorithm, see Resolution Engine. For how the ability types shape the way you cut an application into apps, see Capability Mini-Apps.