Category: Federation & SSO

Federation Proxy

Also known as: Federation Hub, Federation Server Proxy, SAML Proxy

Simply put

A federation proxy is a middleman component that sits between identity providers (the systems that verify who a user is) and relying parties (the applications a user wants to reach). To the identity providers it looks like an application requesting logins, and to the applications it looks like an identity provider supplying them, so both sides only need to connect to the proxy rather than to each other directly. This simplifies connectivity when many identity providers and many applications need to trust one another.

Formal definition

A federation proxy is a component that acts as a logical relying party (RP) to a set of identity providers (IdPs) and simultaneously as a logical IdP to a set of RPs, bridging the two sides through a single point of connectivity (NIST). In deployment, both service providers (SPs)/RPs and IdPs establish federation trust only with the proxy, which mediates and re-issues authentication assertions or tokens between them rather than requiring point-to-point trust across every party. It is commonly implemented as a federation hub that aggregates trust and, depending on the product, may translate or normalize between federation protocols and profiles (for example, brokering across SAML 2.0-based deployments); the specific protocol handling, assertion transformation, and credential collection behavior vary by vendor and configuration. Note that a federation proxy operates at the runtime authentication/federation layer and is distinct from identity governance concerns such as provisioning, access certification, or segregation of duties; authorization decisions at target applications remain out of scope of the proxy's bridging function unless the deployment explicitly configures it otherwise.

Why it matters

As federation deployments grow, the number of point-to-point trust relationships between identity providers and relying parties can expand rapidly. Without a mediating component, every IdP that needs to serve every application must establish and maintain a direct federation trust, along with the associated metadata exchange, certificate rotation, and profile configuration. A federation proxy reduces this to a hub-and-spoke arrangement: each IdP and each application trusts only the proxy, which mediates and re-issues assertions between the two sides. This simplifies onboarding, consolidates where federation trust is managed, and can lower the operational burden of maintaining many bilateral connections.

Because the proxy sits in the authentication path between users, IdPs, and applications, it also becomes a concentration point that warrants careful protection. Every login flow for the applications behind it traverses the proxy, so its availability, the integrity of the assertions it re-issues, and the correctness of its trust configuration directly affect access to all downstream relying parties. In some deployments the proxy also collects credentials or home realm details from clients (as in an AD FS federation server proxy scenario), which places additional security expectations on the component.

It is worth being precise about scope: a federation proxy operates at the runtime authentication and federation layer. It bridges and mediates authentication assertions, but it does not itself perform identity governance functions such as provisioning, access certification, or segregation of duties, and authorization decisions at target applications remain out of scope of its bridging function unless a deployment explicitly configures it to participate. Treating the proxy as a governance or authorization control it was not designed to provide can create gaps in an identity architecture.

Who it's relevant to

Security architects

Architects evaluating how to scale federation across many IdPs and applications should understand the trade-off a federation proxy introduces: it collapses point-to-point trust into a hub-and-spoke model, simplifying connectivity while concentrating the authentication path through a single component that must be designed for availability, integrity, and secure trust configuration.

IAM and federation engineers

Engineers who configure and operate federation trust relationships work directly with proxy behavior, including how the component acts as an RP upstream and an IdP downstream, how it re-issues assertions, and whether it collects credentials or home realm details. Because protocol handling and assertion transformation vary by vendor and configuration, engineers must validate the specific product's behavior rather than assume a standard flow.

System administrators of federation infrastructure

Administrators running products such as AD FS federation server proxies or comparable hubs are responsible for the day-to-day operation of the component that mediates logins, including metadata and certificate management for the trusts terminating at the proxy. Its position in the authentication path makes its uptime and configuration correctness operationally critical.

Compliance and audit stakeholders

Those assessing identity controls should recognize that a federation proxy addresses runtime authentication mediation and does not, by itself, provide identity governance functions such as provisioning, access certification, or segregation of duties. Auditors should look elsewhere in the identity architecture for those controls and confirm the proxy's scope has not been mistaken for governance coverage.

Inside Federation Proxy

Identity Provider (IdP) facing interface

The side of the proxy that acts as a service provider or relying party toward one or more upstream identity providers, consuming assertions or tokens (for example SAML 2.0 assertions or OIDC ID tokens) to establish the authenticated subject.

Relying party (RP) facing interface

The side of the proxy that behaves as an identity provider toward downstream applications or service providers, issuing its own assertions or tokens after the upstream authentication result is received.

Protocol translation/bridging

Logic that maps between federation protocols and profiles, for example translating an inbound SAML 2.0 web SSO assertion into an outbound OIDC Core authentication response, or vice versa, depending on configuration.

Trust and metadata management

Configuration that establishes trust relationships on both sides, typically including signing and encryption keys, entity identifiers, endpoints, and metadata for each connected IdP and RP.

Claim and attribute mapping

Rules that transform, filter, or rename attributes and claims as they pass through, so that identifiers and attributes emitted downstream match what each relying party expects.

Session and token handling

Handling of the proxy's own sessions and the assertions or tokens it issues, which typically involves validating the signatures on inbound assertions and generating newly signed outbound tokens rather than passing the original unchanged.

Common questions

Answers to the questions practitioners most commonly ask about Federation Proxy.

Does a federation proxy authenticate users itself?

Typically, no. A federation proxy acts as an intermediary between identity providers (IdPs) and service providers or relying parties, brokering federation requests and responses rather than serving as the authoritative source of authentication. The actual authentication of a principal usually occurs at an upstream IdP; the proxy relays or transforms the resulting assertions or tokens. In some deployments a proxy is co-located with an IdP function, but the proxying role and the authenticating role are distinct concerns and should not be conflated.

Is a federation proxy the same thing as an identity provider?

Not inherently. To a downstream service provider a proxy often presents itself as an IdP, and to an upstream IdP it often presents itself as a service provider, which is why it is sometimes described as playing both roles. However, this is a brokering posture rather than an assertion that the proxy is the origin of identity. Depending on configuration, the proxy may pass through, transform, or enrich assertions, but the authoritative identity data and authentication event typically originate elsewhere.

How do you handle protocol translation between SAML and OIDC through a federation proxy?

In many deployments a federation proxy terminates one protocol on the upstream side and re-issues on the downstream side, for example accepting a SAML 2.0 assertion from an IdP and issuing an OIDC ID token to a relying party, or vice versa. This requires mapping between the assertion and token models, including translating SAML attributes into JWT claims and reconciling differences such as SAML's XML signature model versus OIDC's JWT signing. Behavior varies by product; you should verify how the proxy maps subject identifiers, audience/entity restrictions, and authentication context so semantics are preserved across the boundary.

How should attribute and claim mapping be configured at a federation proxy?

Configuration depends on the source and target protocols and on what downstream relying parties require. Common practice is to define explicit mappings from inbound attributes or claims to outbound ones, applying transformations, defaults, or filtering as needed. Be deliberate about which attributes are passed through versus dropped, since a proxy can inadvertently over-share identity data. Where the proxy enriches assertions from an additional attribute source, treat that source as a separate component in your data flow and document it accordingly.

What are the trust and key management considerations when deploying a federation proxy?

A federation proxy typically maintains separate trust relationships on each side: it validates upstream IdP signatures and, in turn, signs the assertions or tokens it issues downstream. This means it holds signing keys and must manage certificate or key rotation on both federation edges. Note that signing establishes integrity and origin but is not the same as encryption; if assertion or token confidentiality is required in transit or at rest, that must be configured separately. Because the proxy sits in the trust path, compromise of its keys can affect all connected parties, so key protection and rotation practices warrant particular attention.

What operational and availability concerns arise from introducing a federation proxy?

Placing a proxy in the authentication path introduces an additional component that participates in every federated sign-on it brokers, so its availability generally affects access to all downstream relying parties routed through it. Deployments commonly address this with redundancy and health monitoring. Session and single logout handling can also become more complex, since the proxy may need to correlate upstream and downstream sessions; verify how logout propagation behaves in your configuration. Logging and correlation of the two-sided flow are important for troubleshooting and audit, but the specifics depend on the product and profile in use.

Common misconceptions

A federation proxy authenticates users itself.

A federation proxy typically does not perform primary authentication; it delegates identification and authentication to upstream identity providers and then relays or re-issues the result. It brokers and translates federation flows rather than verifying credentials directly, though some deployments may add step-up or additional factors at the proxy.

Because it sits between IdP and RP, a federation proxy is only about authentication.

The proxy handles federation of authentication results and identity claims, but authorization decisions generally remain the responsibility of downstream relying parties or a separate policy decision point. A proxy can shape the attributes available for those decisions, but it is not itself an authorization enforcement mechanism unless explicitly configured for that purpose.

Signing the assertions or tokens a proxy issues makes them confidential.

Signing provides integrity and origin authenticity, not confidentiality. If claims passing through the proxy are sensitive, encryption of the assertion or token (and transport security) must be configured separately, since a signed token is not the same as an encrypted one.

Best practices

Maintain separate, well-scoped trust configurations for each upstream identity provider and downstream relying party, and keep signing and encryption keys current with a defined rotation process.

Validate signatures and, where required by the profile, encryption on inbound assertions or tokens before issuing any outbound assertion or token, and never blindly relay unvalidated upstream results.

Define explicit claim and attribute mapping rules so that only the attributes each relying party actually needs are passed through, applying filtering to avoid over-sharing identity data.

Encrypt assertions or tokens carrying sensitive claims in addition to signing them, since signing alone does not provide confidentiality, and enforce transport-layer protection on all federation endpoints.

Document which protocols and profiles the proxy bridges (for example SAML 2.0 to OIDC Core) and confirm that the translation preserves subject identifiers, audience restrictions, and expected claim semantics on both sides.

Keep authorization decisions with the appropriate downstream relying party or dedicated policy decision point rather than embedding access-control logic in the proxy, unless a step-up or policy role is a deliberate, documented part of the deployment.