Last modified: Jul 16, 2026

Resource Registry persistence architecture

Database model, event log and blob containers in Resource Registry.

Resource Registry stores resource metadata, access lists and derived resource subjects in PostgreSQL. XACML policies reside in Azure Blob Storage. The model is based on source commit 8cc7866.

Select a diagram to open it at full size in a new tab.

Storage overview

Resource Registry storage overview

PostgreSQL uses a single schema, resourceregistry. The diagrams split that schema by responsibility to keep the details legible. The grouping does not represent separate database schemas.

Resources and resource subjects

Resource and resource-subject tables in resourceregistry

resource_identifier represents the durable identity of a resource and holds change-feed state. resources is a version table where every change receives a new version_id. The current_resources database view selects the latest version of each resource.

resourcesubjects contains subjects derived from the policy. Its composite primary key consists of the resource and subject URNs. The table supports soft deletion and timestamp-based incremental retrieval, but the migrations create no foreign key to the resource tables.

Access lists

Access-list tables in resourceregistry

Access lists use event sourcing with a separate, updated state model. access_list_events is the append-oriented event log. access_list_state, access_list_members_state and access_list_resource_connections_state make reads efficient without replaying all events. version provides optimistic concurrency control.

The event log has no foreign key to the state table. The access-list-to-resource link also has no foreign key after the resource table was versioned. The diagram therefore distinguishes enforced foreign keys from logical links through aggregate_id and resource_identifier.

Blob structure

Blob containers and policy paths in Resource Registry

Resource Registry uses two configurable containers:

  • ResourceRegistryContainer, named resourceregistry by default, stores resource policies as <resource ID>/resourcepolicy.xml
  • MetadataContainer, named metadata by default, stores app policies as <organisation>/<app>/policy.xml

Blob versions allow a specific resource-policy version to be retrieved. Blob leases protect conditional updates against concurrent writes. PostgreSQL does not store the blob path or version ID, but policy_uploaded records whether a policy has been uploaded for the resource.

Scope and planned move

The diagrams show tables, key indexes, the view and storage links. Database functions, sequence implementation, grants and full index names are omitted for readability.

Resource Registry is planned to move into altinn-authorization-tmp. The source link documents the current implementation. Update this page if the move changes migrations, namespaces, containers or data ownership.