Configuring your Apicurio Registry deployment
This chapter explains various configuration options for Apicurio Registry, such as authentication, logging, cloud events, and health checks on OpenShift.
Configuring Apicurio Registry authentication and authorization with Keycloak
This section explains how to manually configure authentication and authorization options for Apicurio Registry using Keycloak.
Alternatively, for details on how to configure these settings automatically, see the Apicurio Registry Operator documentation. |
You can enable authentication for the Apicurio Registry web console and core REST API using Keycloak based on OAuth using OpenID Connect (OIDC). The same Keycloak realm and users are federated across the Apicurio Registry web console and core REST API using OpenID Connect so that you only require one set of credentials.
Apicurio Registry provides role-based authorization for default admin, write, and read-only user roles. Apicurio Registry also provides content-based authorization at the schema or API level, where only the creator of the registry artifact can update or delete it. Apicurio Registry authentication and authorization settings are disabled by default.
-
Keycloak is installed and running. For more details, see Keycloak user documentation.
-
Apicurio Registry is installed and running.
-
In the Keycloak Admin Console, create a Keycloak realm for Apicurio Registry. By default, Apicurio Registry expects a realm name of
registry
. For more details on creating realms, see Getting Started with Keycloak. -
Create a Keycloak client for the Apicurio Registry API. By default, Apicurio Registry expects the following settings:
-
Client ID:
registry-api
-
Client Protocol:
openid-connect
-
Access Type:
bearer-only
You can use the defaults for the other client settings.
If you are using Keycloak service accounts, the client Access Type must be confidential
instead ofbearer-only
.
-
-
Create a Keycloak client for the Apicurio Registry web console. By default, Apicurio Registry expects the following settings:
-
Client ID:
apicurio-registry
-
Client Protocol:
openid-connect
-
Access Type:
public
-
Valid Redirect URLs:
http://my-registry-url:8080/*
-
Web Origins:
+
You can use the defaults for the other client settings.
-
-
In your Apicurio Registry deployment on OpenShift, set the following Apicurio Registry environment variables to configure authentication using Keycloak:
Table 1. Configuration for Apicurio Registry authentication Environment variable Description Type Default AUTH_ENABLED
If set to
true
, the environment variables that follow are required.String
false
KEYCLOAK_URL
The URL of the Keycloak authentication server to use. Must end with
/auth
.String
None
KEYCLOAK_REALM
The Keycloak realm used for authentication.
String
registry
KEYCLOAK_API_CLIENT_ID
The client ID for the Apicurio Registry REST API.
String
registry-api
KEYCLOAK_UI_CLIENT_ID
The client ID for the Apicurio Registry web console.
String
apicurio-registry
For an example of setting environment variables on OpenShift, see Configuring Apicurio Registry health checks on OpenShift. -
Set the following option to
true
to enable Apicurio Registry user roles in Keycloak:Table 2. Configuration for Apicurio Registry role-based authorization Environment variable Java system property Type Default value ROLE_BASED_AUTHZ_ENABLED
registry.auth.role-based-authorization
Boolean
false
-
When Apicurio Registry user roles are enabled, you must assign Apicurio Registry users to at least one of the following default user roles in your Keycloak realm:
Table 3. Default user roles for registry authentication and authorization Role Read artifacts Write artifacts Global rules Summary sr-admin
Yes
Yes
Yes
Full access to all create, read, update, and delete operations.
sr-developer
Yes
Yes
No
Access to create, read, update, and delete operations, except configuring global rules. This role can configure artifact rules.
sr-readonly
Yes
No
No
Access to read and search operations only. This role cannot configure any rules.
-
Set the following to
true
to enable owner-only authorization for updates to schema and API artifacts in Apicurio Registry:Table 4. Configuration for owner-only authorization Environment variable Java system property Type Default value REGISTRY_AUTH_OBAC_ENABLED
registry.auth.owner-only-authorization
Boolean
false
-
For details on configuring non-default user role names, see Apicurio Registry authentication and authorization configuration options
-
For an open source example application and Keycloak realm, see Docker Compose-based example of using Keycloak with Apicurio Registry
-
For details on how to use Keycloak in a production environment, see the Keycloak documentation
-
For details on custom security configuration, the see Quarkus Open ID Connect documentation
Apicurio Registry authentication and authorization configuration options
Apicurio Registry provides authentication options for OpenID Connect with Keycloak or HTTP basic authentication.
Apicurio Registry provides authorization options for role-based and content-based approaches:
-
Role-based authorization for default admin, write, and read-only user roles.
-
Content-based authorization for schema or API artifacts, where only the owner of the artifacts or artifact group can update or delete artifacts.
Apicurio Registry authentication and authorization options are disabled by default. |
This chapter provides details on the following configuration options:
Apicurio Registry authentication using OpenID Connect with Keycloak
You can set the following environment variables to configure authentication for the Apicurio Registry web console and API using Keycloak:
Environment variable | Description | Type | Default |
---|---|---|---|
|
Enables or disables authentication in Apicurio Registry. When set to |
String |
|
|
The URL of the Keycloak authentication server to use. Must end with |
String |
- |
|
The Keycloak realm used for authentication. |
String |
- |
|
The client ID for the Apicurio Registry REST API. |
String |
|
|
The client ID for the Apicurio Registry web console. |
String |
|
Apicurio Registry authentication using HTTP basic
By default, Apicurio Registry supports authentication using OpenID Connect. Users (or API clients) must obtain an access token to make authenticated calls to the Apicurio Registry REST API. However, because some tools do not support OpenID Connect, you can also configure Apicurio Registry to support HTTP basic authentication by setting the following configuration option to true .
|
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
|
Boolean |
|
Apicurio Registry role-based authorization
You can set the following option to true
to enable role-based authorization in Apicurio Registry:
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
|
Boolean |
|
You can then configure role-based authorization to use roles included in the user’s authentication token (for example, granted when authenticating using Keycloak), or to use role mappings managed internally by Apicurio Registry.
Use roles assigned in Keycloak
To enable using roles assigned by Keycloak, set the following environment variables:
Environment variable | Description | Type | Default |
---|---|---|---|
|
When set to |
String |
|
|
The name of the role that indicates a user is an admin. |
String |
|
|
The name of the role that indicates a user is a developer. |
String |
|
|
The name of the role that indicates a user has read-only access. |
String |
|
When Apicurio Registry is configured to use roles from Keycloak, you must assign Apicurio Registry users to at least one of the following user roles in Keycloak. However, you can configure different user role names using the environment variables in Configuration for Apicurio Registry role-based authorization using Keycloak.
Role name | Read artifacts | Write artifacts | Global rules | Description |
---|---|---|---|---|
|
Yes |
Yes |
Yes |
Full access to all create, read, update, and delete operations. |
|
Yes |
Yes |
No |
Access to create, read, update, and delete operations, except configuring global rules and import/export. This role can configure artifact rules only. |
|
Yes |
No |
No |
Access to read and search operations only. This role cannot configure any rules. |
Manage roles directly in Apicurio Registry
To enable using roles managed internally by Apicurio Registry, set the following environment variables:
Environment variable | Description | Type | Default |
---|---|---|---|
|
When set to |
String |
|
When using internally managed role mappings, users can be assigned a role using the /admin/roleMappings
endpoint in the Apicurio Registry REST API. For more details, see Apicurio Registry REST API documentation.
Users can be granted exactly one role: ADMIN
, DEVELOPER
, or READ_ONLY
. Only users with admin
privileges can grant access to other users.
Apicurio Registry admin-override configuration
Because there are no default admin users in Apicurio Registry, it is usually helpful to configure another way for users to be identified as admins. You can configure this admin-override feature using the following environment variables:
Environment variable | Description | Type | Default |
---|---|---|---|
|
Enables the admin-override feature. |
String |
|
|
Where to look for admin-override information. Only |
String |
|
|
The type of information used to determine if a user is an admin. Values depend on the value of the FROM variable, for example, |
String |
|
|
The name of the role that indicates a user is an admin. |
String |
|
|
The name of a JWT token claim to use for determining admin-override. |
String |
|
|
The value that the JWT token claim indicated by the CLAIM variable must be for the user to be granted admin-override. |
String |
|
For example, you can use this admin-override feature to assign the sr-admin
role to a single user
in Keycloak, which grants that user the admin role. That user can then use the /admin/roleMappings
REST API (or associated UI) to grant roles to additional users (including additional admins).
Apicurio Registry owner-only authorization
You can set the following options to true
to enable owner-only authorization for updates to artifacts or artifact groups in Apicurio Registry:
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
|
Boolean |
|
|
|
Boolean |
|
When owner-only authorization is enabled, only the user who created an artifact can modify or delete that artifact.
When owner-only authorization and group owner-only authorization are both enabled, only the user who created an artifact group has write access to that artifact group, for example, to add or remove artifacts in that group.
Apicurio Registry authenticated read access
When the authenticated read access option is enabled, Apicurio Registry grants at least read-only access to requests from any authenticated user in the same organization, regardless of their user role.
To enable authenticated read access, you must first enable role-based authorization, and then set the following option to true
:
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
|
Boolean |
|
For more details, see Apicurio Registry role-based authorization.
Apicurio Registry anonymous read-only access
In addition to the two main types of authorization (role-based and owner-based authorization), Apicurio Registry supports an anonymous read-only access option.
To allow anonymous users, such as REST API calls with no authentication credentials, to make read-only
calls to the REST API, set the following option to true
:
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
|
Boolean |
|
-
For an example of how to set environment variables in your Apicurio Registry deployment on OpenShift, see Configuring Apicurio Registry health checks on OpenShift
-
For details on configuring custom authentication for Apicurio Registry, the see Quarkus Open ID Connect documentation
Configuring the Apicurio Registry web console
You can configure the Apicurio Registry web console specifically for your deployment environment or to customize its behavior. This section provides details on how to configure optional environment variables for the Apicurio Registry web console.
-
You have already installed Apicurio Registry.
Configuring the web console deployment environment
When a user navigates their browser to the Apicurio Registry web console, some initial configuration settings are loaded. Two important configuration properties are:
-
URL for core Apicurio Registry server REST API
-
URL for Apicurio Registry web console client
Typically, Apicurio Registry automatically detects and generates these settings, but there are some deployment environments where this automatic detection can fail. If this happens, you can configure environment variables to explicitly set these URLs for your environment.
Configure the following environment variables to override the default URLs:
-
REGISTRY_UI_CONFIG_APIURL
: Specifies the URL for the core Apicurio Registry server REST API. For example,https://registry.my-domain.com/apis/registry
-
REGISTRY_UI_CONFIG_UIURL
: Specifies the URL for the Apicurio Registry web console client. For example,https://registry.my-domain.com/ui
Configuring the web console in read-only mode
You can configure the Apicurio Registry web console in read-only mode as an optional feature. This mode disables all features in the Apicurio Registry web console that allow users to make changes to registered artifacts. For example, this includes the following:
-
Creating an artifact
-
Uploading a new version of an artifact
-
Updating an artifact’s metadata
-
Deleting an artifact
Configure the following environment variable:
-
REGISTRY_UI_FEATURES_READONLY
: Set totrue
to enable read-only mode. Defaults tofalse
.
Configuring Apicurio Registry logging
You can set Apicurio Registry logging configuration at runtime. Apicurio Registry provides a REST endpoint to set the log level for specific loggers for finer grained logging. This section explains how to view and set Apicurio Registry log levels at runtime using the Apicurio Registry /admin
REST API.
-
Get the URL to access your Apicurio Registry instance, or get your Apicurio Registry route if you have Apicurio Registry deployed on OpenShift. This simple example uses a URL of
localhost:8080
.
-
Use this
curl
command to obtain the current log level for the loggerio.apicurio.registry.storage
:$ curl -i localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage HTTP/1.1 200 OK [...] Content-Type: application/json {"name":"io.apicurio.registry.storage","level":"INFO"}
-
Use this
curl
command to change the log level for the loggerio.apicurio.registry.storage
toDEBUG
:$ curl -X PUT -i -H "Content-Type: application/json" --data '{"level":"DEBUG"}' localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage HTTP/1.1 200 OK [...] Content-Type: application/json {"name":"io.apicurio.registry.storage","level":"DEBUG"}
-
Use this
curl
command to revert the log level for the loggerio.apicurio.registry.storage
to its default value:$ curl -X DELETE -i localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage HTTP/1.1 200 OK [...] Content-Type: application/json {"name":"io.apicurio.registry.storage","level":"INFO"}
Configuring Apicurio Registry event sourcing
You can configure Apicurio Registry to send events when changes are made to the registry. For example, Apicurio Registry can trigger events when schema and API artifacts are created, updated, deleted, and so on. You can configure Apicurio Registry to send events to your applications and to third-party integrations in this way.
There are different protocols available for transporting the events. The currently implemented protocols are HTTP and Apache Kafka. However, regardless of the protocol, the events are sent using the CNCF CloudEvents specification.
All of the event types are defined in io.apicurio.registry.events.dto.RegistryEventType
. For example, the event types include:
-
io.apicurio.registry.artifact-created
-
io.apicurio.registry.artifact-updated
-
io.apicurio.registry.artifact-rule-created
-
io.apicurio.registry.global-rule-created
You can configure cloud events in Apicurio Registry using Java system properties or equivalent environment variables.
-
You must have an application that you want to send Apicurio Registry cloud events to. For example, this can be a custom application or a third-party application.
Configuring Apicurio Registry event sourcing using HTTP
The example in this section shows a custom application running at http://my-app-host:8888/events
.
-
When using the HTTP protocol, set your Apicurio Registry configuration to send events to a your application as follows:
-
registry.events.sink.my-custom-consumer=http://my-app-host:8888/events
-
-
If required, you can configure multiple event consumers as follows:
-
registry.events.sink.my-custom-consumer=http://my-app-host:8888/events
-
registry.events.sink.other-consumer=http://my-consumer.com/events
-
Configuring Apicurio Registry event sourcing using Apache Kafka
The example in this section shows a Kafka topic named my-registry-events
running on my-kafka-host:9092
.
-
When using the Kafka protocol, set your Kafka topic as follows:
-
registry.events.kafka.topic=my-registry-events
-
-
You can set the configuration for the Kafka producer using the
KAFKA_BOOTSTRAP_SERVERS
environment variable:-
KAFKA_BOOTSTRAP_SERVERS=my-kafka-host:9092
Alternatively, you can set the properties for the kafka producer using the
registry.events.kafka.config
prefix, for example:registry.events.kafka.config.bootstrap.servers=my-kafka-host:9092
-
-
If required, you can also set the Kafka topic partition to use to produce events:
-
registry.events.kafka.topic-partition=1
-
-
For more details, see the CNCF CloudEvents specification
Configuring Apicurio Registry health checks on OpenShift
You can configure optional environment variables for liveness and readiness probes to monitor the health of the Apicurio Registry server on OpenShift:
-
Liveness probes test if the application can make progress. If the application cannot make progress, OpenShift automatically restarts the failing Pod.
-
Readiness probes test if the application is ready to process requests. If the application is not ready, it can become overwhelmed by requests, and OpenShift stops sending requests for the time that the probe fails. If other Pods are OK, they continue to receive requests.
The default values of the liveness and readiness environment variables are designed for most cases and should only be changed if required by your environment. Any changes to the defaults depend on your hardware, network, and amount of data stored. These values should be kept as low as possible to avoid unnecessary overhead. |
-
You must have an OpenShift cluster with cluster administrator access.
-
You must have already installed Apicurio Registry on OpenShift.
-
You must have already installed and configured your chosen Apicurio Registry storage in Strimzi or PostgreSQL.
-
In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges.
-
Click Installed Operators > Apicurio Registry.
-
On the ApicurioRegistry tab, click the Operator custom resource for your deployment, for example, example-apicurioregistry.
-
In the main overview page, find the Deployment Name section and the corresponding
DeploymentConfig
name for your Apicurio Registry deployment, for example, example-apicurioregistry. -
In the left navigation menu, click Workloads > Deployment Configs, and select your
DeploymentConfig
name. -
Click the Environment tab, and enter your environment variables in the Single values env section, for example:
-
NAME:
LIVENESS_STATUS_RESET
-
VALUE:
350
-
-
Click Save at the bottom.
Alternatively, you can perform these steps using the OpenShift
oc
command. For more details, see the OpenShift CLI documentation.
Environment variables for Apicurio Registry health checks
This section describes the available environment variables for Apicurio Registry health checks on OpenShift. These include liveness and readiness probes to monitor the health of the Apicurio Registry server on OpenShift. For an example procedure, see Configuring Apicurio Registry health checks on OpenShift.
The following environment variables are provided for reference only. The default values are designed for most cases and should only be changed if required by your environment. Any changes to the defaults depend on your hardware, network, and amount of data stored. These values should be kept as low as possible to avoid unnecessary overhead. |
Liveness environment variables
Name | Description | Type | Default |
---|---|---|---|
|
Number of liveness issues or errors that can occur before the liveness probe fails. |
Integer |
|
|
Period in which the threshold number of errors must occur. For example, if this value is 60 and the threshold is 1, the check fails after two errors occur in 1 minute |
Seconds |
|
|
Number of seconds that must elapse without any more errors for the liveness probe to reset to OK status. |
Seconds |
|
|
Comma-separated list of ignored liveness exceptions. |
String |
|
Because OpenShift automatically restarts a Pod that fails a liveness check, the liveness settings, unlike readiness settings, do not directly affect behavior of Apicurio Registry on OpenShift. |
Readiness environment variables
Name | Description | Type | Default |
---|---|---|---|
|
Number of readiness issues or errors that can occur before the readiness probe fails. |
Integer |
|
|
Period in which the threshold number of errors must occur. For example, if this value is 60 and the threshold is 1, the check fails after two errors occur in 1 minute. |
Seconds |
|
|
Number of seconds that must elapse without any more errors for the liveness probe to reset to OK status. In this case, this means how long the Pod stays not ready, until it returns to normal operation. |
Seconds |
|
|
Readiness tracks the timeout of two operations:
If these operations take more time than the configured timeout, this is counted as a readiness issue or error. This value controls the timeouts for both operations. |
Seconds |
|
All the available Apicurio Registry configuration options
This section contains a list of the configuration options available for Apicurio Registry.
Category api
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
|
Include stack trace in errors responses |
|
|
|
Disable APIs |
Category auth
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
OIDC client ID |
|
|
|
|
|
Auth admin override claim |
|
|
|
|
Auth admin override claim value |
|
|
|
|
Auth admin override enabled |
|
|
|
|
Auth admin override from |
|
|
|
|
Auth admin override role |
|
|
|
|
Auth admin override type |
|
|
|
|
Anonymous read access |
|
|
|
|
Authenticated read access |
|
|
|
|
Enable basic auth client credentials |
|
|
|
Auth client secret |
|
|
|
|
|
Enable authentication |
|
|
|
|
Artifact owner-only authorization |
|
|
|
|
Artifact group owner-only authorization |
|
|
|
|
Enable role based authorization |
|
|
|
|
Auth roles source |
|
|
|
|
Auth roles admin |
|
|
|
|
Auth roles developer |
|
|
|
|
Auth roles readonly |
|
|
|
|
Auth tenant owner admin enabled |
|
|
|
Auth token endpoint |
Category cache
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
|
Registry cache enabled |
Category ccompat
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
|
Legacy ID mode (compatibility API) |
|
|
|
|
Maximum number of Subjects returned (compatibility API) |
|
|
|
|
Canonical hash mode (compatibility API) |
Category download
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
|
Download link expiry |
Category events
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
Events Kafka sink enabled |
Category health
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
Ignored liveness errors |
|
|
|
|
|
Counter reset window duration of persistence liveness check |
|
|
|
|
Disable logging of persistence liveness check |
|
|
|
|
Error threshold of persistence liveness check |
|
|
|
|
Status reset window duration of persistence liveness check |
|
|
|
|
Counter reset window duration of persistence readiness check |
|
|
|
|
Error threshold of persistence readiness check |
|
|
|
|
Status reset window duration of persistence readiness check |
|
|
|
|
Timeout of persistence readiness check |
|
|
|
|
Counter reset window duration of response liveness check |
|
|
|
|
Disable logging of response liveness check |
|
|
|
|
Error threshold of response liveness check |
|
|
|
|
Status reset window duration of response liveness check |
|
|
|
|
Counter reset window duration of response readiness check |
|
|
|
|
Error threshold of response readiness check |
|
|
|
|
Status reset window duration of response readiness check |
|
|
|
|
Timeout of response readiness check |
|
|
|
|
Storage metrics cache check period |
Category import
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
The import URL |
Category kafka
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
Events Kafka topic |
|
|
|
|
Events Kafka topic partition |
Category limits
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
|
Cache check period limit |
|
|
|
|
Max artifact labels |
|
|
|
|
Max artifact properties |
|
|
|
|
Max artifacts |
|
|
|
|
Max artifact description length |
|
|
|
|
Max artifact label size |
|
|
|
|
Max artifact name length |
|
|
|
|
Max artifact property key size |
|
|
|
|
Max artifact property value size |
|
|
|
|
Max artifact requests per second |
|
|
|
|
Max schema size (bytes) |
|
|
|
|
Max total schemas |
|
|
|
|
Max versions per artifacts |
Category log
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
Log level |
Category mt
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
|
Enable multitenancy |
|
|
|
|
Enable multitenancy authorization |
|
|
|
Multitenancy reaper every |
|
|
|
|
|
Multitenancy reaper max tenants reaped |
|
|
|
|
Multitenancy reaper period seconds |
|
|
|
|
Multitenancy context path type base path |
|
|
|
|
Enable multitenancy context path type |
|
|
|
|
Enable multitenancy request header type |
|
|
|
|
Multitenancy request header type name |
|
|
|
|
Enable multitenancy subdomain type |
|
|
|
|
Multitenancy subdomain type header name |
|
|
|
|
Multitenancy subdomain type location |
|
|
|
|
Multitenancy subdomain type pattern |
|
|
|
Organization ID claim name |
|
|
|
|
Tenant manager auth client ID |
|
|
|
|
Tenant manager auth client secret |
|
|
|
|
Tenant manager auth enabled |
|
|
|
|
Tenant manager auth token expiration reduction ms |
|
|
|
|
Tenant manager auth url configured |
|
|
|
|
Tenant manager SSL Ca path |
|
|
|
|
Tenant manager URL |
|
|
|
|
|
Tenants context cache check period |
Category redirects
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
Enable redirects |
|
|
|
|
Registry redirects |
Category rest
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
|
Max size of the artifact allowed to be downloaded from URL |
|
|
|
|
Skip SSL validation when downloading artifacts from URL |
Category store
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
|
Datasource Db kind |
|
|
|
Datasource jdbc URL |
|
|
|
|
|
SQL init |
Category ui
:
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
|
UI OIDC tenant enabled |
|
|
|
UI APIs URL |
|
|
|
|
|
UI auth OIDC client ID |
|
|
|
|
UI auth OIDC redirect URL |
|
|
|
|
UI auth OIDC URL |
|
|
|
|
UI auth type |
|
|
|
|
UI context path |
|
|
|
|
UI read-only mode |
|
|
|
|
UI features settings |
|
|
|
Overrides the UI root context (useful when relocating the UI context using an inbound proxy) |