System Configuration

Appmixer offers a variety of system configuration options for advanced use cases, allowing you to finely tune the behavior of its underlying workflow and integration engine. To access and set these configuration options, navigate through the Appmixer Backoffice interface to the "System -> System Configuration" page.

Please be aware that certain configuration changes may not take immediate effect without restarting the Appmixer engine. For customers with a Self-Managed Appmixer installation, restarting the engine can be done at your convenience to apply the new settings. For those with a hosted Appmixer tenant, it's advisable to reach out to our support team at [email protected]. Our team can provide guidance on how to effectively set these configuration options and assist with any necessary engine restarts to ensure your configurations are applied as intended.

Configuration options

Below is a list of available configuration options, accompanied by a brief explanation for each and their default values. These defaults are used by Appmixer in instances where no specific value is provided:

Key

Detail

Default value

Needs restart

API_USER_CREATE_SCOPE

By default, the POST /user API is open to enable the sign-in feature for everyone. This option can restrict the access to this endpoint. It takes a list of scopes (comma-separated). If the value is not null, then a JWT token has to be used to call this API. Typically, the value is set to admin.

null

APP_NAME

This will for example appear in the head title of a sign-in popup for Api Key services.

Appmixer

AUTH_HUB_AUTOMATIC

If the auth-hub system plugin is on and this value is true, all OAuth requests for unconfigured services will go through the Authentication Hub. It means that if you install Slack, for example, and do not configure the clientId and clientSecret the engine will use the Appmixer Authentication Hub for Slack authorization.

true

DEFAULT_USER_VENDOR

Vendor assigned to newly created users.

No value

AUTH_POPUP_DISPLAY_ERR

Whether to display validation errors from the authentication modules.

true

AUTH_POPUP_TIMEOUT_ERR

How many seconds before automatically closing the Connecting Account Failed popup window.

BROKER_MESSAGE_ACK_TIMEOUT

Timeout for message processing.

1500000

COMPONENT_FACTORY_TIMEOUT

An attempt to create a component will fail after this timeout.

300000

COMPONENT_RECEIVE_TIMEOUT

A message will be retried if the receive() function does not return within this timeout.

1380000

LIMIT_FLOW_UPDATE_BYTES

The max size in bytes of a flow descriptor to be able to be saved.

2097152

LIMIT_CC_ARCHIVE_MAX_BYTES

Maximum size in bytes for custom components.

10485760

LIMIT_WEBHOOK_BYTES

Maximum payload size in bytes for webhook components.

1048576

WEBHOOK_REQUEST_TIMEOUT

Timeout in milliseconds for webhook component requests.

10000

LIMIT_COMPONENT_STATIC_CALL_MAX_BYTES

Maximum size in bytes of the payload for component static calls.

104857600

PUBLIC_FILES_PREFIX

Public files (needed usually for domain verification) can be served from different paths. Path prefixes have to be separated by :

/:/.well-known

RETRY_BACKOFF

In case of an error, a message for a Component is rescheduled for another attempt. A back-off strategy is used. This value defines the number of attempts and the number of minutes between them.

1,5,60,300,720

DISPATCHER_PREFETCH_COUNT

The maximum number of Rabbit messages being dispatched at the same time.

500

INPUT_QUEUE_PREFETCH_COUNT

The maximum number of outgoing Rabbit messages waiting for aknowledgement at the time in the Input Queue. Subsequent incoming messages will not be sent until pending messages are aknowledged.

300

WEBHOOK_PREFETCH_COUNT

This is for webhooks from Appmixer to registered URLs. This is the amount of webhook messages that will be processing at a time.

WEBHOOK_RETRY_COUNT

Number of times that Appmixer will retry sending a webhook. Applies for all webhooks.

WEBHOOK_RETRY_INTERVAL

Initial interval in milliseconds for retries. Subsequent retries will take longer (multiplied by an internal factor).

30000

WEBHOOK_RETRY_MAX

Maximum interval in milliseconds between retries.

1800000

WEBHOOK_USER_CREATED

URL that will be called when new user is created (sign-up).

No value

WEBHOOK_FLOW_COMPONENT_ERROR

URL that will be called when a running flow encounters an error.

No value

WEBHOOK_FLOW_COMPONENT_ERROR_INCLUDE_QUOTA

Include quota errors among the errors sent to the registered webhook URL.

false

WEBHOOK_FLOW_COMPONENT_ERROR_INCLUDE_RETRY

Include retry attempts among the errors sent to the registered webhook URL. If false, the error will be sent, when all 30 attempts to process a message fail. If true, every failed attempt will be sent.

false

WEBHOOK_FLOW_STOPPED

URL that will be called when a flow is stopped due to an incompatible module upgrade.

No value

STRICT_COOKIES

If set to true, the engine will reject any incoming HTTP requests that have cookies that don't comply with the HTTP cookies RFC specification.

false

GARBAGE_COLLECTOR_CONTINUITY_SCOPES_TTL

The maximum time in days before continuity scopes are garbage collected. A continuity scope is a state of a flow including data from the flow runtime needed to continue the flow from a certain component onwards. For example, the Plivo.SendSMSAndWaitForReply sends an SMS and waits for an event (webhook) from Plivo that contains an SMS with a reply. The continuity scope contains all the data needed to continue the flow at a later time (when the webhook from Plivo is received which can take hours to days.

100

GC_FILES_ENABLED

If the Garbage collector for files is enabled.

true

GC_FILES_RULES

Rules for the Gargabge collector.

See below.

IDP_CONFIG

Identity provider configuration. Please see Configuring Single-Sing-On for more informations.

No value

IDP_ROLES_PATH

Identity provider configuration. Please see Configuring Single-Sing-On for more informations.

No value

IDP_DEFAULT_REDIRECT

Identity provider configuration. Please see Configuring Single-Sing-On for more informations.

No value

GC_FILES_RULES

 [
    {
        "scope": "user",

        /**
         * The GC will never delete files created in the past TTL (in hours). By default,
         * set to 720 hours. The reason is to prevent the GC from removing files that could be needed by the
         * flows.
         */
        "ttl": 720,   // 30 days

        /**
         * The user will be blocked from saving any files if the limit is reached.
         */
        "hardLimit": 2000000000   // 2 GB
    }
]

You can have different rules for different user scopes:
[
    { "scope": "user:, "ttl": 720, "hardLimit": 2000000000 },
    { "scope": "admin", "ttl":1440, "hardLimit": 90000000000 }
]

Configuring Single-Sign-On

Configuring Single Sign-On (SSO) for Appmixer allows your users to authenticate using their existing identity provider. Appmixer supports OpenID Connect (OIDC) and SAML standards for seamless integration.

Required Configuration Parameters

To set up SSO, you'll need to gather the following information from your Identity Provider (IdP):

idp_type: This specifies the authentication method. It can be either oidc or saml.
authorization_url: This is the URL where users will be redirected to log in via your IdP.
issuer: A unique string that identifies your identity provider.
metadata_url: A publicly accessible URL provided by your IdP that contains essential information for the authentication process.

Appmixer-Specific Parameters

The following parameters are typically not part of a standard IdP configuration and will likely need to be added manually:

domains: A list of domains for which you want to enable SSO. Any user with an email address from a domain listed here will be redirected to your IdP's authentication page. For example: ["yourcompany.com", "example.org"]
role_mapping: This object maps roles from your IdP to Appmixer's roles. Appmixer currently supports admin and user roles. For example, if your IdP uses "administrator" for admins and "member" for users, your mapping might look like: {"admin": "administrator", "user": "member"}

Parameters Based on Authentication Type

You'll also need additional parameters depending on whether you're using SAML or OIDC:

SAML

certificate: The certificate used to sign SAML requests.

OIDC

client_id: An identifier for your client application.
client_secret: A secret identifier for your client application.
token_url: The URL where Appmixer can obtain a new OIDC token.

Important Considerations Most of these parameters will be provided when you download the configuration from your Identity Provider. You'll primarily need to manually add the domains and role_mapping fields.

It's crucial that your metadata_url is publicly accessible. This is generally true for cloud-based identity providers like AWS IAM and Google ID. However, if you're self-hosting your IdP, you might need to adjust your network configuration to ensure its public accessibility. Appmixer does not currently support configuring a proxy to access an IdP; this must be handled via your hosting machine's network settings. If you encounter issues, please contact our support center. Configuration Examples Once you've gathered all the necessary information, your configuration JSON should resemble one of the following examples:

{
    "idp_type": "oidc",
    "client_id": "a361cbac-a420-42ca-8f07-fc3520d5c36b",
    "client_secret": "0841fb03-55b8-4b0d-aeb0-330374348c09",
    "issuer": "my-idp",
    "domains": ["client.io"],
    "token_url": "https://idp.example.com/auth/realms/apm/protocol/openid-connect/token",
    "authorization_url": "https://idp.example.com/auth/realms/apm/protocol/openid-connect/auth",
    "metadata_url": "https://idp.example.com/auth/realms/apm/.well-known/openid-configuration",
    "role_mapping": {
        "admin": "adm",
        "user": "usr"
    }
}

{
    "idp_type": "saml",
    "authorization_url": "https://idp.example.com/auth/realms/apm/protocol/saml",
    "metadata_url": "https://idp.example.com/auth/realms/apm/protocol/saml/descriptor",
    "issuer": "my-idp",
    "certificate": "MIIClTCCAX0CBgGV0[...]6smvQM7VU=",
    "domains": ["localhost", "client.io"],
    "role_mapping": {
        "admin": "adm",
        "user": "usr"
    }
}

Applying Your Configuration

Paste your finalized configuration JSON as a new Appmixer System Configuration with the key IDP_CONFIG.

Additional Parameters

IDP_HANDLE_ROLES: Identity Providers (IdPs) may manage either Authentication and Authorization or just Authentication. By default, Appmixer delegates only authentication to the IdP. To allow the IdP to manage authorization as well (importing roles from the IdP), set this variable to true

Additional Parameters by Authentication Type

OIDC

IDP_ROLES_PATH: (Only required if IDP_HANDLE_ROLES is true) This is the path within your IdP's authentication response where a user's roles can be found. The value varies between Identity Providers. Refer to the table below for common IdPs:

Identity Provider

Roles Path

Keycloak

realm_access.roles

Google ID

~~<not supported>~~

Amazon IAM

SAML

IDP_DEFAULT_REDIRECT: This should be the URL of your login page. It's used as a fallback if an authentication error prevents Appmixer from retrieving a valid redirect URL from the identity provider.

IDP_SAML_EXPECT_SIGNED_ASSERTIONS : Whether each single assertion will be signed separately. Defaults to false

PreviousGetting Started NextGetting Started

Last updated 2 months ago

Was this helpful?