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.

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 is a combination of the “central pool” and “local proxy” models. 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.