To provide a highly available, performant, scalable authorization solution for your applications, Aserto utilizes a hub and spoke model. The central hub (otherwise known as the Aserto Control Plane) provides the central capabilities for managing policies, life-cycle management, identity data, and audit logs. The spokes are the autonomous authorizer instances running as close to your application as possible.

Running an authorizer instance close to the application has several advantages in terms of availability, performance, and scalability:

• The authorizer instances operate autonomously. Each instance has its own local instance of the policy image for the application it serves and a local instance of the identity property data, which allows the authorizer to continue operating even when it is disconnected from the central control plane. When reconnected, it will synchronize its state and publish the decision logs.
• This setup enables scaling the number of authorizer instances to increase throughput and redundancy.
• Having the authorizer operate close to the application instance minimizes the network latency between the two, which is desirable given the high number of authorization requests that need to be handled.

Edge Authorizer flavors

A couple of flavors of edge authorizers are available:

• Onebox: a single-tenant, single policy authorizer with a built-in web UI, to be used as a developer workstation.
• Sidecar: a single-tenant, single policy authorizer without a web UI. The sidecar is the general edge authorizer flavor with a small surface area, which can be used as a sidecar but also as a local service instance.

Deployment and operation

Edge authorizers can be deployed in various ways based on the application and target environment needs and requirements. In its most basic form, an authorizer is a Docker container instance, which can be deployed as a standalone service, sidecar, or development workstation.

An edge authorizer always operates in the context of a (single) Aserto organization and is assigned a specific policy to serve. This information is provided to the edge authorizer via a configuration file, which it uses to send a discovery call to the Aserto control plane.

Discovery flow

When a new edge authorizer is started, the discovery flow will be initiated:

1. A configuration file (config.yaml) is passed to the authorizer when it is started
2. The authorizer makes a discovery call to the control plane, passing the policy ID, authorizer API key, and tenant ID.
3. The authorizer receives a response from the control plane including the configuration that the edge authorizer will need pointing it to the specific policy bundle.
4. The authorizer validates and merges configuration settings
5. Finally, the authorizer creates a runtime configuration

Runtime flow

When the edge authorizer has been bootstrapped it will transition to the runtime flow:

In this state, it will spin up two timer-based background tasks: The first is the discovery updates flow, which executes the discovery request described above to retrieve configuration updates. These updates include updates of the policy in case of a new version as well as configuration changes for the plugins, concretely the edge directory plugin. When a new policy version is available, the policy will be downloaded and applied to the authorizer.

A second time-based background task will synchronize the identity data from the central directory to the edge authorizer when the edge directory plugin is enabled. By default, directory synchronization is turned off and can be enabled in the Aserto console.

Summary

Since authorization is an operation that happens for every application request, the architecture supporting it must be highly scalable and performant. To ensure continuous availability, the authorizer must be able to operate even when it is disconnected from the central control plane. In this post, we reviewed how the edge authorizer architecture allows for all of these requirements to be satisfied. We also took a look at the discovery and runtime flows used by edge authorizers, ensuring they are properly registered with the control plane and that they are always kept up to date with policy and directory information.

For detailed instructions for setting up edge authorizers, check out our documentation.