Proxy app deployment architectures
The Maverics Identity Orchestrator is designed to help solve a range of identity problems, and therefore can be deployed using different patterns to best solve the problem at hand. This article describes the most common deployment architectures, and the associated pros and cons.
A note about using load balancers and cookies:
When an orchestrator is being used as a single-host proxy (proxying to a single app), using a cookie set by a load balancer will function as normal. When the orchestrator serves as an IDP, using a default load balancer cookie also works well.
When the orchestrator is reverse proxying to multiple applications and setting its session cookie on a root domain (for example, on example.com with apps on alpha.example.com and beta.example.com), we recommend using the orchestrator’s session cookie, as many load balancers (AWS ALB, AVI) don’t support modifying the domain of cookies they set.
Central Pool
In this deployment model, a centralized pool of Orchestrator instances are used to protect applications. This model works well when a team is comfortable making network changes, and would prefer to not interface with application teams regularly.
Pros
- Centralized configuration management.
- Minimal app owner engagement required.
- Contained footprint of Orchestrators.
Cons
- Apps are susceptible to side channel traffic unless mitigations are put in place.
- Networking changes required.
- Added latency, although the delta is usually sub-second.
Local Proxy
The local proxy pattern co-locates the Orchestrator on the same host as the application. This model works well for header-based apps, or for application teams that control the auth flow for their app.
Pros
- No additional infrastructure required.
- No networking changes required.
- Negligible impact on application performance.
Cons
- App owner engagement required.
- Additional load on existing application servers.
- Some web server changes required.
RP-IDP
The RP-IDP architecture combines the “local proxy” model (relying parties) with a pool of Orchestrator(s) that act as an IDP. This pattern works particularly well for administrators who are moving off a legacy web access management solution such as SiteMinder or Oracle Access Manager, but can be used successfully for a variety of use cases.
Pros
- Centralized configuration management.
- No networking changes required.
- Battle-tested architecture.
Cons
- Some app owner engagement required.
- Additional load on existing application servers.
- Some web server changes required.