Skip to main content
Version: ACE 5

Security

The goal of this page is to explain recommended security practices for ACE installation and ways how API consumers can be Authenticated and Authorized in the Production environment.

Dynamic APIs​

Dynamic APIs are APIs that are built by Domain Experts.

Dynamic APis can be either Anonymous or Authenticated, depending on the business logic built into these APIs.

Anonymous APIs are used by consumers who have not yet been identified in the system and are usually in inception phase of the business process (for example a new Customer who seeks to get a quotation for a financial product).

Authenticated APIs are used by consumers that are already know to the system and are coming to access assets that they have previously stored in the system (for example an existing Customer reviewing his quotes and policies).

API gateway​

Recommended way to protect ACE Dynamic APIs is through API gateway (for example API Management in case of Azure).

Customer connects to API gateway to access Dynamic APIs.

Customer is redirected by Mobile or Web application to Identity Provider (Keycloak) to identify himself, if he is attempting to access application functional areas that require authentication.

Use the Network firewall to make sure that ACE Dynamic APIs port can be accessed only locally through API gateway.

API gateway acts as an additional layer of security and can be used to:

  • make sure that only certified APIs are accessible via proper Authentication method,
  • track expiration and validity of authentication tokens of existing Customers,
  • ensure quality of the service by enforcing service limits (for example, API calls per minute), to make sure that Customers do not overwhelm the Backend system,
  • enable Data Loss Protection by certifying outgoing connections that ACE container can make.

System to System Authentication​

Once Customer is authenticated in API gateway, there is no practical reason to authenticate him in ACE or in Backend systems.

It is however necessary to authenticate connectivity between the systems. There are several methods how to authenticate with the peer system:

  • API key,
  • Username and Password (Basic Authorization),
  • Mutual SSL

Authorization​

ACE can act as an additional authorization layer:

  • in case if Backend does not support anonymous users, ACE can limit the scope of Backend functionality that new Customers can access,
  • in case if Backend lacks granularity of data row level security, but rather has system to system APIs that restrict user to certain functional zones (for example, Backend can allow access to only Policy objects for a particular Agent, but lacks capabilities to limit user access to a particular Policy object).

CORS​

danger

If ACE APIs are consumed by Web or Mobile applications and application uses different domain than ACE, then it is necessary to configure CORS headers not to allow requests from any domain.

In development mode ACE runtime must include Designer web public URL in CORS allowed origins.

There are 2 ways of configuring CORS - either through ACE configuration or through Ingress (or API gateway).

ACE built-in CORS​

If CORS is enabled in ACE (CORS_ENABLED=true), then by default ACE allows CORS requests from any domain.

It is possible to configure ACE to allow requests only from trusted domains by setting CORS_ALLOWED_ORIGINS environment variable.

All headers are allowed by default, and it is not possible to limit allowed headers in ACE.

Kubernetes ingress​

It is possible to achieve more fine-grained control by using Kubernetes Ingress or API gateway. In this case, it is necessary to set CORS_ENABLED=false in ACE configuration.

Example below uses Kubernetes Nginx Ingress Controller to configure CORS headers:

# Turn on CORS in Ingress
nginx.ingress.kubernetes.io/enable-cors: 'true'
# Limit origin only to required applications
# In development mode it's required to include Designer web public URL
# It is possible to specify wildcards (e.g. https://*.sapienspaas.com) and list multiple domains 
nginx.ingress.kubernetes.io/cors-allow-origin: "https://my-application.sapienspaas.com" 
# Allow only specific headers if necessary, it is mandatory to include Authorization header (included in default nginx config)
# nginx.ingress.kubernetes.io/cors-allow-headers: "Authorization,My-Custom-Header"

See detailed Nginx Ingress Controller CORS configuration.

Secrets​

Any secrets (for example passwords) must be passed as the environment variables to the Runtime server container. Environment variables are accessible in flow as $env object properties.

danger

Environment variables with secrets should not be stored unencrypted on the persistent storage (i.e. as workspace variables).

Recommended approach is to load secrets from vault (e.g. Azure Key Vault) and pass them to the Runtime server container as (for example in Kubernetes) as environment variables.

Development environment​

Development environment is used by Domain Experts to build and test ACE flows and APIs.

Designer Web​

danger

Designer Web is not intended to be used in Production environment.

Designer Web is intended to be used only in Development environment and must be protected from public access either by VPN and/or by authentication (Keycloak or other IDP, see configuration).

Runtime server​

danger

Do not use development mode in Production environment!

Runtime server has 2 modes - production and development.

production mode is the default mode and must be used in Production and other environments which doesn't use Designer Web.

Runtime server in development mode exposes additional APIs, which are used to support API and flow testing from Designer Web. It is necessary to enable development mode only in Development environment where Designer Web is used.

It is also recommended to set ALLOWED_REPOSITORIES environment variable to limit access to only required repositories on runtime server in development mode.

Repository access (Git tokens)​

Designer Web relies on Git tokens to connect to git repository which is also used as a data storage for ACE flows and APIs.

It is recommended that users issue a separate Git token for Designer Web with access only to required repository and use it only in Development environment.

Deployment APIs​

danger

Deployment APIs must not be exposed publicly without protection!

Deployment API server is used to deploy ACE flows and APIs to Runtime server if ACE_WORKSPACE_STORAGE is set to mongo.

The purpose of ACE development APIs is to expose and allow a manipulation of the ACE configuration.

Deployment API server must not be exposed publicly unprotected. There are several options how to protect these APIs.

SSH​

firewall and ssh

Administrator user uses the same credentials and transport as to connect to Host to manage the operating system, to establish SSH tunnels necessary to manage the ACE configuration.

Use the Network firewall to make sure that ACE management APIs port can be accessed only locally using SSH tunnel.

Authentication sidecar​

Proxy (i.e. oauth2-proxy) is deployed as a sidecar to act as an API Gateway and Identity Provider.

Administrator user connects to sidecar to manage the ACE configuration.

Use the Network firewall to make sure that ACE management APIs port can be accessed only locally through Authentication sidecar.

OpenID Connect external Identity Provider (Keycloak)​

note

ACE container is deployed as HTTP service and requires a Sidecar or Ingress to handle HTTPS.

ACE can be configured to use external OpenID Connect compatible Identity Provider to authenticate the Administrator users.

When Administrator user connects to ACE container, he is redirected to external Identity Provider to authenticate himself.

Use the Network firewall to make sure that ACE management APIs port can be accessed only from the trusted network.

BullMQ Admin​

danger

This service is for internal use only and must not be exposed publicly unprotected.

It is possible to use same protection methods as for Deployment APIs.

Provided BullMQ admin is optional and shouldn't be installed if scheduled jobs are not used.

It is also possible to use other tools to manage BullMQ queues as there is no ACE specific logic in the BullMQ admin service.