ACP deployment

Get to know all available deployment types for Authorization Control Plane (ACP).

ACP deployment in a nutshell

ACP comes with three types of deployment:

Hybrid SaaS deployment

There are nine components that are present in this deployment type:

  • ACP frontend

  • ACP backend

    • Configuration Store, Service Identity

    • Distributed Authorization Context Store

    • Reporting / Visualization / Analytics (optional)

    • Configuration and Secrets Management (optional)

  • Distributed Enforcement

  • Protected client applications

  • Protected API Services

The following diagram illustrates a simplified architecture of the Hybrid SaaS deployment type:

Hybrid SaaS deployment diagram

The ACP frontend applications communicate with the ACP backend part via HTTPs requests. Load balancers are responsible for distributing traffic between ACP nodes. Each node can communicate over the Transport Layer Security (TLS) with:

  • Configuration Store and Service Identity that consist of distributed SQL databases

  • Distributed Authorization Context Store that consists of Hazelcast or Redis nodes

It can also optionally communicate over the Transmission Control Protocol (TCP) with:

  • Reporting / Visualization / Analytics part that consists of Elastic nodes

  • Configuration and Secrets Management that consists of Vault clusters deployed with Consul

Protected client applications can communicate with the ACP backend part via TCP and with the Distributed Enforcement via HTTPs requests. The Distributed Enforcement component consists of the MircoPerimeter™ Authorizer and integrated API Gateways and is responsible for the API protection and enforcement. It can communicate with the ACP backend to enforce authorization policies. Additionally, the API Gateways act as a reverse proxy to accept all authorized API calls and return the appropriate result.

Note

At the moment, the ACP Hybrid SaaS deployment is available only in the United States.

ACP on K8s

Another way to deploy ACP is to use Kubernetes (K8s) with Helm Charts. Kubernetes is a container or a microservice platform that makes it possible to orchestrate computing, networking, and storage of the infrastructure workloads. Helm is a package manager for Kubernetes. It uses a packaging format called charts. A chart is a collection of files that describe a related set of resources stored on K8s. They collect the manifest files and docker addresses. You can use Helm charts to deploy ACP with all its backend architecture.

Read more

Get familiar with the Kubernetes, Helm, and Helm Charts documentation.

ACP deployment on K8s is very similar to the deployment using standard Linux packages. Using Kind, you can add the ACP repository to Helm and install desired packages with a single command.

At the moment, ACP on K8s is provided with the following charts:

  • Standalone version of Authorization Control Plane

  • ACP Openbanking that collects all Cloudentity Open Banking applications to provide easy to operate end-to-end K8s cluster.

  • ACP with dependencies that include the charts for Hazelcast and CockroachDB.

All charts can be configured before installation by overwriting the default values provided in the values.yaml file.

MicroPerimeter™ Authorizer

MicroPerimeter™ Authorizer can be deployed using Linux packages that consist of lightweight containers, pods, or operators. You can either deploy MicroPerimeter™ by yourself using Linux packages, or you can use it as a part of the ACP Hybrid SaaS Deployment, where it is provided out of the box.

Multitenancy

ACP comes with built-in multitenancy that features logical data separation and data encryption. For every deployment of ACP, you can create multiple tenants and adjust their workspaces (authorization servers) configuration according to your needs.

ACP multitenancy diagram simplified

Each tenant inside the ACP cluster features dedicated OAuth servers, dedicated security domains, and independent authorization profiles.

Read more

Read more about multitenancy.