Architecture at a glance

A deployment of Authonomy Resilience is a set of one or more instances, each of which is autonomous. An instance federates with external identity providers, holds its own canonical view of the identity population, runs the request router and the native floor, and writes its own audit. Where a deployment has multiple instances, they do not coordinate at the authentication-request layer.

This page sketches the components of one instance and the two axes a deployment configures.

Components of an instance

Each instance carries the surface needed to serve authentication independently. Five components are load-bearing:

Federation. Outbound integration with the customer’s external identity providers — OIDC and SAML — to broker authentication when a primary path is healthy.

Canonical view. A local copy of the identity population the instance serves, kept current against the customer’s authoritative source within a configured drift window. The canonical view is what the instance uses when an upstream source is unreachable.

Health monitor. A per-method liveness signal feeding the router. Each external IdP and the native floor are monitored independently.

Router. The mechanism that selects a login method per request, evaluating the health monitor against a priority-ordered ladder configured for the application or the population.

Native authentication and credential store. The continuity floor: when no external method is reachable, Authonomy authenticates against credential material it holds locally. The credential store is backed by the instance database by default, or externalized to a keystore (HSM, cloud KMS) for deployments with stronger key-custody requirements.

A sixth surface, audit, is written synchronously by the instance. Every routing decision, method selection, token issuance, and sync operation lands in the local audit trail before the action completes.

The two configuration axes

A deployment is shaped by two orthogonal choices. The product page introduces them as the failover ladder and the placement; this is the same distinction stated in implementation terms.

Composition — the priority-ordered set of login methods the router selects among. Cloud-IdP-then-native, two-cloud-then-native, cloud-then-on-prem-AD-then-native, or a four-rung ladder with both cloud independence and an AD continuity rung. The composition describes what the router selects among.

Placement — where instances run. A single instance serving the customer’s applications; one instance per site or per failure domain; or a redundant set of instances at each site. The placement describes where the router runs.

Composition and placement are selected together, not in sequence. A retail estate with hundreds of stores typically uses a per-store placement so that a WAN severance at one store doesn’t take its authentication with it. A single-region SaaS typically uses a single instance with a multi-rung composition. A manufacturing line with $100K-per-hour downtime cost uses both — site-deployed placement for connectivity-loss tolerance, and a deep ladder for provider-loss tolerance.

What’s not on this page

The architecture supports more depth than this overview admits — failure domains, replication topology, the drift-window contract, the credential-store placement decision, the audit-aggregation boundary. The full specification covers each in detail. For first-pass evaluation, the components and the two axes above are the load-bearing concepts.