Skip to content

Role Based Access Control

Fusion Metadata Registry (FMR) uses Role Based Access Control (RBAC) to determine what an authenticated user is allowed to see and do. Rather than assigning permissions directly to individual users, FMR grants permissions to external user groups and then checks whether the signed-in user belongs to any of those groups.

This approach makes access easier to manage because the user lifecycle is handled in your identity provider, while FMR only needs to know which groups should have which registry permissions.

How RBAC works in FMR

The process is:

  1. A user signs in using one of the configured authentication options.
  2. As part of authentication, FMR requests the user's profile information, including their group membership.
  3. FMR compares those group names with the configured entries in the Role Mapping function.
  4. If a match is found, FMR grants the permissions associated with that mapped group.
  5. The user can then work only within the scope allowed by those permissions.

In practice, FMR does not normally need a list of individual users. It only needs the group names returned by the authentication service and the corresponding role mappings configured in the registry.

Key principles

  • Authentication and authorisation are separate. Authentication confirms who the user is, while RBAC determines what they can do after they sign in.
  • Permissions are assigned to groups, not directly to named users.
  • Group names must match the names returned by your authentication service.
  • Permissions are granted in FMR through the Role Mapping function.
  • A single group can be mapped to one or more organisations, depending on the access you want to provide.
  • A user can receive multiple permissions if they belong to multiple mapped groups.

Available permission types

FMR supports the following broad permission types.

Administrator

Administrator access provides system-wide administration privileges. This is the highest level of access and is intended for trusted registry administrators.

Typical uses include:

  • maintaining security settings
  • managing role mappings
  • performing other registry administration tasks

Administrator access should normally be granted sparingly and mapped to a dedicated administrative group.

Agency

An Agency permission allows users to create and maintain structural metadata artefacts for the specified Agency.

This is suitable for users who are responsible for maintaining SDMX structures such as codelists, concepts, data structure definitions, dataflows, and related artefacts owned by that Agency.

For example, if a group is mapped to Agency BIS, members of that group can work with structural metadata for Agency BIS, but not automatically for other Agencies.

Data Provider

A Data Provider permission allows users to submit data as the specified Data Provider.

This type of access is normally used when data reporting responsibilities are delegated to specific reporting organisations. Mapping a group to a Data Provider ensures that members of that group can act as that provider when submitting data.

For example, a group mapped to Data Provider BIS:DP1 can submit data for that Data Provider, but not for unrelated providers unless additional mappings exist.

Data Consumer

A Data Consumer permission allows users to query for data.

This is typically used for users or groups that need read/query access without requiring administrative or structural maintenance privileges.

How role mappings fit into RBAC

The Role Mapping function is the administrative screen used to connect external groups to FMR permissions. It links:

  • Administrators
  • Agencies
  • Data Providers
  • Data Consumers

to the group names supplied by your authentication source, such as Active Directory or another directory-backed identity provider.

If RBAC is enabled but no matching role mappings have been defined, users may be able to authenticate successfully but still be unable to perform any useful actions in FMR.

Detailed instructions for creating and maintaining those mappings are provided in Maintaining Role Mappings.

Example

The following example shows how RBAC is commonly organised:

  • Group YADMIN is mapped to Administrator
  • Group GOT-AGENCY is mapped to Agency GOT
  • Group GOT-DATA-PROVIDERS is mapped to one or more Data Providers under Agency GOT
  • Group GOT-DATA-CONSUMERS is mapped to one or more Data Consumer entries

With this arrangement:

  • members of YADMIN can administer the registry
  • members of GOT-AGENCY can maintain structural metadata for Agency GOT
  • members of GOT-DATA-PROVIDERS can submit data for the mapped provider organisations
  • members of GOT-DATA-CONSUMERS can query data according to their assigned access

Administrative guidance

When planning RBAC in FMR, it is good practice to:

  • create separate groups for different responsibilities rather than using one broad group for everything
  • keep Administrator access separate from business-as-usual Agency or Data Provider access
  • use meaningful, stable group names in the identity provider
  • review role mappings whenever organisations, reporting responsibilities, or support teams change
  • test with representative user accounts to confirm that the expected permissions are being applied

Troubleshooting RBAC

If a user can sign in but cannot access the expected functions, check the following:

  1. The user authenticated successfully using the intended authentication method.
  2. The authentication service is returning the expected group names.
  3. The group name returned to FMR exactly matches the configured Role Mapping entry.
  4. The correct Agency, Data Provider, Data Consumer, or Administrator mapping has been assigned.
  5. The user belongs to the correct external group.

In most cases, RBAC issues are caused by missing role mappings, mismatched group names, or a user being in the wrong external group.

Related page

For step-by-step instructions on editing, importing, exporting, and deleting mappings, see Maintaining Role Mappings.