Instance configuration

The following configuration settings can be administered for each instance of the Verified Orchestration platform.

These settings are controlled via the Configuration page in Composer.

To change settings, you will need to be a member of the Instance admin user role.

CORS origins

If you are accessing the Verified Orchestration API or OIDC endpoint from a web application, CORS origins will need to be configured against each instance (sandbox and production).

• Subdomains can be matched using a regular expression; e.g. ^https://([a-z0-9]+[.])*yourcompany\.com$
• For your sandbox, you may want to allow local development origins e.g. ^http(s?)://localhost(:\d+)?$

Additional tenant IDs

If you want to allow the users from the tenants other than your home tenant to access the Verified Orchestration API, those tenant IDs will need to be configured against each instance (sandbox and production).

Application labels

As you onboard applications, you can supply user-friendly labels, helping users to understand which apps are issuing or requesting presentation of credentials.

To supply a label for an app, provide the app's object ID from the Enterprise Apps list in the Azure Portal, along with the label.

Example application label mapping:

App object ID (OID)	Label
00000000-0000-0000-0000-000000000000	Your app name

Identity issuer labels

You may integrate several identity providers as a source of issuee identity data. Identities are uniquely identified by the issuer and identifier fields. We recommend you standardise use of the issuer field across different applications to avoid duplicate representations of the same identity. We recommend using the tenant ID or iss (issuer) claim from JWTs for the issuer field.

To supply a label for an identity issuer, provide the issuer's identifier along with the label.

Note: your home tenant is automatically labelled.

Example issuer label mapping:

Issuer	Label
00000000-0000-0000-0000-000000000000	Tenant label
https://b2cinstanceb2clogin.com/00000000-0000-0000-0000-000000000000/v2.0/	B2C label

GraphQL security settings

The Verified Orchestration API uses GraphQL for querying and mutating data. To ensure the API is not misused, the following security settings are configured out of the box with sensible defaults. However, these settings can be adjusted to suit your requirements.

Rule	Default	Description
Max Aliases	30	Limit the number of aliases in a GraphQL document.
Max Depth	12	Limit the depth of a GraphQL document.
Max Directives	50	Limit the number of directives in a GraphQL document.
Max Tokens	2500	Limit the number of tokens in a GraphQL document.

If you need to adjust GraphQL security settings, please contact the Verified Orchestration team to make changes on your behalf.