Add Roles and Permissions

Add Role-Based Access Control (RBAC) for organizations and users within an ecosystem. Define Roles and grant permissions to chosen participants by using Role Metadata.

Prerequisites

• Domains available and configured within the platform.

  Add a Domain if one does not exist.

• Get an Access Token with the directory:website scope if you want to create or manage Roles and their Metadata using Connect's APIs.

Create Role

Roles can be created only for an existing authorization domain. A role cannot exist independently—it must be associated with a domain.

1. Select Reference Data > Domains and Roles.

2. Use the dropdown to expand the Domain where you want to add a role.

3. Select + Add Role.

4. Fill in all the required fields and save.

Field Name	Description
Authorisation Domain Name	Common name of the associated Domain
Role Name	Name of the role
Role Type	Type of the Role Federation: Defines how an organization's client application metadata is presented to the broader ecosystem. Federation roles influence the interaction pattern between the client application and the ecosystem. They shape client endpoint behavior and relations with Authorisation Servers. Directory: Directory roles determine how an organization's client applications communicate with Connect's APIs. Modifications to Directory roles are applied across all client applications registered within a framework.
Is this role exclusive?	Controls whether an organization can have other roles assigned. If an organization has an exclusive role assigned, it cannot have any other roles assigned.
Description	Description of the Role

Add Role Metadata

1. Select Reference Data > Domains and Roles.

2. Using the dropdown button, expand the Domain where you want to configure a role by defining its metadata.

3. Select the role for which you wish to add metadata.

4. Select New Metadata.

5. Fill in the fields defining the role metadata.

   
   

   Metadata	Description
   Entity Type	Type of the entity to which the metadata applies. Read more about available entity types.
   Claim Name	Metadata type—specific information the client application can request or the authorization server can support. Read more about metadata types.
   Policy Operator	Action on the metadata parameter: a value check, value modification, or both. Read more about policy operators.
   Data Type	Type of the data stored in metadata.
   Value	Value of the role's metadata.

6. Save new role metadata.

Available Entity Types

Entity Type	Description
OpenID Provider	The OP is the authorization server / identity provider, in an OpenID Connect flow. It authenticates the user and issues the ID Token and Access Token.
OAuth Authorization Server	The authorization server authenticates client applications and issues access and/or refresh tokens.
OpenID Relying Party	The RP is the client application that uses OIDC. It redirects the user to the OP for authentication and then relies on the returned ID/access token.
OAuth Client	The client application is the application that gets authorization from the user and authenticates to the authorization server in order to get access tokens for API access.

Difference between OP/Authorization Server and RP/OAuth Client

While OpenID Provider and OAuth Authorization server or Relying Parties and OAuth clients seem the same, there are some subtle differences.

An OpenID Provider is always an OAuth Authorization Server, but an Authorization Server is not always an OpenID Provider. An OpenID Relying Party is always an OAuth client, but not all OAuth clients are Relying Parties.

In both cases, the difference lies in the metadata profile issued for the given entity type. On Raidiam Connect, there are no functional differences between both pairs of types but different sections of metadata being issued in case OpenID Federation is being used as the underlying Trust Scheme in the Trust Framework.

For example, OAuth Dynamic Client Registration Metadata is issued only for OpenID Relying Parties–which does not need to be a case for OAuth client. For OpenID Provider, the metadata defined in OpenID Connect Discovery will be issued, which may not be the case for an OAuth authorization server.

Available Metadata Types

claim

Entity Type	Metadata Type description	Example
OpenID Provider / OAuth Authorization Server	Specific pieces of information the OP/Authorization Server may issue as parts of ID Tokens or Access Tokens to convey information about the client, user, or authentication event.	name, family_name
OpenID Relying Party / OAuth Client	Specific pieces of information requested by an organization's client applications to be included in Access Tokens or ID Tokens to convey information about the client, user, or authentication event.	name, family_name

claim_in_verified_claims

Verified claims differ from regular claims by enabling strong assurance of a claim according to the OpenID Connect Specification for Identity Assurance.

Entity Type	Metadata Type description	Example
OpenID Provider / OAuth Authorization Server	Specific and verified pieces of information the OP/Authorization Server may issue as parts of ID Tokens or Access Tokens to convey information about the client, user, or authentication event.	name, family_name
OpenID Relying Party / OAuth Client	Specific and verified pieces of information requested by an organization's client applications to be included in Access Tokens or ID Tokens to convey information about the client, user, or authentication event.	name, family_name

For example of how verified claims look like, see the OIDC for Identity Assurance specification section #5.

scope

Entity Type	Metadata Type description	Example
OpenID Provider / OAuth Authorization Server	Scopes the authorization server can support to enable client access.	email, openid, profile
OpenID Relying Party / OAuth Client	Used by client applications to specify the access scopes the client requests from the OP or authorization server.	email, openid, profile

It is considered a best practice to limit the requested scopes to only those absolutely necessary. Learn more by reading the RFC9700 Best Current Practice for OAuth 2.0 Security: Access Token Privilage Restriction section

If you are adding metadata to a role of the directory type and wish to enable client applications to access Connect's APIs, Raidiam's OAuth Authorisation Server accepts three values: directory:website, directory:software, and directory:admin.

Within Connect, all client applications are by default assigned the directory:software scope to enable them to access the platform's APIs.

response_type

Entity Type	Metadata Type description	Example
OpenID Provider / OAuth Authorization Server	Defines the response types the authorization server can use when responding to token or authorization requests.	code token
OpenID Relying Party / OAuth Client	Determines the response type the client application can request when making requests to the Authorisation Server's pushed_authorization_request_endpoint, authorization_endpoint, and token_endpoint endpoints.	code token

For more information about response types and their detailed descriptions, see the OAuth 2.0 Multiple Response Type Encoding Practices specification section #5.

grant_type

Entity Type	Metadata Type description	Example
OpenID Provider / OAuth Authorization Server	Defines the grant types the authorization server must support and use for client application access.	authorization_code
OpenID Relying Party / OAuth Client	Specifies the OAuth grant type (flow) the client application can use when requesting authorization from the user or a token from the authorisation server.	authorization_code

If you are adding metadata to a role of the directory type and wish to enable client applications to access Connect's APIs, Raidiam's OAuth Authorisation Servers accepts two values: authorization_code, or client_credentials.

Within Connect, all client applications are by default assigned the client_credentials flow to enable them to access the platform's APIs.

is_resource_server

Specifies whether the entity represents a resource server or not.

One of: true, false

authorization_details_type

Entity Type	Metadata Type description	Example
OpenID Provider / OAuth Authorization Server	Defines the fine-grained permissions (authorization details types) the authorization server can use when issuing tokens to client applications.	payment_amount
OpenID Relying Party / OAuth Client	Enables client applications to specify their fine-grained authorization requirements when using the OAuth 2.0 Rich Authorization Requests (RAR) grant type.	payment_amount

Available Policy Operators

Operator	Description
value	The value must match exactly what is defined.
default	Provides a default value when none is supplied elsewhere.
one_of	The value must be one item from the allowed list.
subset_of	The value must be a subset of the allowed policy list.
superset_of	The value must contain all required items, but may include more.
add	Appends values to the policy’s existing list.

Delete Role

For audit purposes, Raidiam only permits Ecosystem Administrators to soft-delete Roles by disabling them.

You can disable a Role by selecting the Disable button (access forbidden sign under Actions) or by using the Update Authorisation Domain Role and setting the role's status to inactive.

Manage Roles Using APIs

Raidiam Connect allows organisations to integrate with the following APIs for Authorisation Domain Management:

• Create Role

• Get Role by Name

• Get All Roles

• Update Role

For Metadata, you can integrate with the following APIs:

• Associate Metadata with Role

• Get All Metadata Associated with Role

• Get Metadata Associated with Role

• Update Role's Metadata

Next Steps

Assign roles to Organisations.