A clearing house must accept both SAML 2.0 and OpenID Connect logins from member organisations for years — how do you sequence it?

seniorshould knowfreq 42%

answer

contain both standards at one place
applications should speak only one
per member, never a global switch
both connections live for a while
retire on zero traffic, not on a date

basics

~20 s

Terminate both standards at a proxying identity provider and re-issue one internal credential, so applications speak a single standard. Then cut over member by member behind a dual-acceptance window, moving low-volume members first, and retire each old connection only when its traffic reaches zero.

solid answer

~50 s

Decide first that the estate speaks one standard internally, and put a proxying identity provider at the edge that terminates whichever standard a member speaks and re-issues that internal credential. Applications then never learn that two standards exist, which is what keeps the migration from touching every service. Second, make the choice of standard a per-member property in the member registry, never a global switch, and give each member a dual-acceptance window in which its old and its new federated connection both work; you cut over one member at a time and can reverse a single member without reversing anything else. Third, sequence by risk: instrument which members arrive over which standard, move a low-volume member whose full business cycle you can observe, and retire an old connection only when its traffic has genuinely reached zero. Accept two real limits: a proxy cannot forward attributes or logout behaviour an upstream never sent, and logout semantics differ between the standards.

Decide first that the estate speaks **one** standard internally, and put a **proxying identity provider** at the edge that terminates whichever standard a member speaks and re-issues that internal credential. Applications then never learn that two standards exist, which is what keeps the migration from touching every service. Second, make the choice of standard a **per-member** property in the member registry, never a global switch, and give each member a **dual-acceptance window** in which its old and its new federated connection both work; you cut over one member at a time and can reverse a single member without reversing anything else. Third, sequence by risk: instrument which members arrive over which standard, move a low-volume member whose full business cycle you can observe, and retire an old connection only when its traffic has genuinely reached zero. Accept two real limits: a proxy cannot forward attributes or logout behaviour an upstream never sent, and logout semantics differ between the standards.

code

pseudocode · 15 lines

pseudocode

function accept_member_login(member, inbound):
    standard = member_registry.standard_for(member)   // per member, never global

    if standard is "saml2" then
        result = terminate_saml2(inbound)
    else if standard is "oidc" then
        result = terminate_oidc(inbound)
    else
        reject "member speaks a standard this deployment does not terminate"

    if member_registry.in_cutover_window(member) then
        // both connections stay live; record which one carried this login
        record_path_used(member, standard)

    return reissue_internal_credential(result)

go deeper

for a junior

Recall that an estate can accept more than one federation standard at once, and that the usual shape is to convert them at one place so applications only ever see a single credential.

for a middle

Explain the containment: a proxying identity provider terminates whichever standard the member speaks and re-issues one internal credential, and the choice of standard is recorded per member.

for a senior

Demonstrate the cutover discipline — per-member dual-acceptance windows, instrumentation before the first move, low-volume members first, retirement on zero traffic — and name what the proxy cannot do.

for a principal

Own the bet: you are concentrating availability risk in one component and accepting that some member organisations will never migrate, in exchange for keeping two standards out of every application for years.

The decision that makes everything else tractable

A long-lived two-standard estate is not a migration problem, it is a containment problem. If two standards reach your applications, every application carries two code paths, two failure modes and two sets of assumptions, and no member can move without a coordinated release. Contain both at the edge instead.

A proxying identity provider terminates whichever standard the member speaks and re-issues a single internal credential. Downstream, there is one standard, one library and one validation path. The entire two-standard problem becomes the responsibility of one component you operate — and, crucially, one component you can instrument.

Note which proxy this is: an identity provider that consumes one federation standard and issues another. It is not an HTTP forward proxy and not a network access broker.

Make the standard a property of the member, not of the estate

The second decision that makes cutovers survivable is where the choice of standard lives. It belongs in the member registry — the register of accredited member organisations — as an attribute of each member, alongside the connection details. A global switch means every member moves on one night; a per-member attribute means the migration is forty small changes, each independently reversible.

The dual-acceptance window

For each member, there is a period in which both its federated connections are live:

Stand up the new connection alongside the old one and prove it with a real login.
Point that member's people at the new path while the old one stays accepted.
Watch, for a full business cycle rather than a quiet afternoon — including whatever periodic event the member actually does, such as a renewal or an onboarding round.
Retire the old connection for that member only when its traffic has reached zero and stayed there.

The window is what converts a cutover from an event into an observation. Its cost is the period in which two paths to the same member identity are live, which is exactly as long as your evidence requires and no longer.

Which side moves first

Sequencing guidance that holds up:

Move what you control before what you negotiate. Your own applications and your proxying identity provider change on your schedule; a member organisation's identity provider changes on theirs.
Move a low-volume member first, not the largest one. You are buying information, and a small member gives you the same defects at a fraction of the blast radius.
Move members with in-house integration teams before members who will need a supplier engagement, because their feedback arrives in days rather than quarters.
Leave the incumbent-heavy members last, and budget for some of them never moving at all. A plan that only succeeds if every member migrates is not a plan.

What a proxying identity provider cannot do

Be honest about the limits, because they shape the cutover:

It cannot create data. If the upstream standard's login did not carry an attribute, the re-issued credential cannot contain it. Attribute coverage per member is a pre-cutover check, not a post-cutover discovery.
It cannot harmonise what the standards say about logout. The two standards take different positions on how a session ending is signalled, and a proxy forwards what it is given. Name the divergence in the plan and decide what behaviour the estate guarantees; the mechanics belong to each standard's own material.
It cannot hide an outage. One component now stands between every member and every application, so its availability is the federation's availability, and it needs the operational treatment that implies.

What to instrument before you move anything

You cannot sequence what you cannot see. Before the first cutover, record per login: which member, which standard, which connection, and whether it succeeded. That gives you three things the plan depends on — a true inventory of who speaks what, the zero-traffic signal that authorises retiring an old connection, and the evidence to reverse a single member quickly when something is wrong.

Decision	The answer that holds up	The failure it prevents
Where two standards meet	At one proxying identity provider	Two code paths in every application
Where the standard is recorded	Per member, in the member registry	A single global cutover night
How a member moves	Dual-acceptance window, then retire	An irreversible switch
Which member moves first	A low-volume one you can watch	Learning the defects at maximum scale
When the old path dies	When that member's traffic is zero	Retiring a path someone still uses

The summary an interviewer wants: one place where two standards meet, one internal credential, the standard recorded per member, and a per-member window that makes each cutover observable and reversible.

## The decision that makes everything else tractable A long-lived two-standard estate is not a migration problem, it is a **containment** problem. If two standards reach your applications, every application carries two code paths, two failure modes and two sets of assumptions, and no member can move without a coordinated release. Contain both at the edge instead. A **proxying identity provider** terminates whichever standard the member speaks and re-issues a single internal credential. Downstream, there is one standard, one library and one validation path. The entire two-standard problem becomes the responsibility of one component you operate — and, crucially, one component you can instrument. Note which proxy this is: an identity provider that consumes one federation standard and issues another. It is not an HTTP forward proxy and not a network access broker. ## Make the standard a property of the member, not of the estate The second decision that makes cutovers survivable is where the choice of standard lives. It belongs in the **member registry** — the register of accredited member organisations — as an attribute of each member, alongside the connection details. A global switch means every member moves on one night; a per-member attribute means the migration is forty small changes, each independently reversible. ## The dual-acceptance window For each member, there is a period in which **both** its federated connections are live: 1. Stand up the new connection alongside the old one and prove it with a real login. 2. Point that member's people at the new path while the old one stays accepted. 3. Watch, for a full business cycle rather than a quiet afternoon — including whatever periodic event the member actually does, such as a renewal or an onboarding round. 4. Retire the old connection for that member only when its traffic has reached zero and stayed there. The window is what converts a cutover from an event into an observation. Its cost is the period in which two paths to the same member identity are live, which is exactly as long as your evidence requires and no longer. ## Which side moves first Sequencing guidance that holds up: - **Move what you control before what you negotiate.** Your own applications and your proxying identity provider change on your schedule; a member organisation's identity provider changes on theirs. - **Move a low-volume member first**, not the largest one. You are buying information, and a small member gives you the same defects at a fraction of the blast radius. - **Move members with in-house integration teams before members who will need a supplier engagement**, because their feedback arrives in days rather than quarters. - **Leave the incumbent-heavy members last**, and budget for some of them never moving at all. A plan that only succeeds if every member migrates is not a plan. ## What a proxying identity provider cannot do Be honest about the limits, because they shape the cutover: - **It cannot create data.** If the upstream standard's login did not carry an attribute, the re-issued credential cannot contain it. Attribute coverage per member is a pre-cutover check, not a post-cutover discovery. - **It cannot harmonise what the standards say about logout.** The two standards take different positions on how a session ending is signalled, and a proxy forwards what it is given. Name the divergence in the plan and decide what behaviour the estate guarantees; the mechanics belong to each standard's own material. - **It cannot hide an outage.** One component now stands between every member and every application, so its availability is the federation's availability, and it needs the operational treatment that implies. ## What to instrument before you move anything You cannot sequence what you cannot see. Before the first cutover, record per login: which member, which standard, which connection, and whether it succeeded. That gives you three things the plan depends on — a true inventory of who speaks what, the zero-traffic signal that authorises retiring an old connection, and the evidence to reverse a single member quickly when something is wrong. | Decision | The answer that holds up | The failure it prevents | |---|---|---| | Where two standards meet | At one proxying identity provider | Two code paths in every application | | Where the standard is recorded | Per member, in the member registry | A single global cutover night | | How a member moves | Dual-acceptance window, then retire | An irreversible switch | | Which member moves first | A low-volume one you can watch | Learning the defects at maximum scale | | When the old path dies | When that member's traffic is zero | Retiring a path someone still uses | The summary an interviewer wants: *one place where two standards meet, one internal credential, the standard recorded per member, and a per-member window that makes each cutover observable and reversible.*

A member's new connection is live and working. What evidence authorises you to retire its old one?
Zero traffic on the old connection for that member across a full business cycle, not a quiet week. That means per-login instrumentation recording member, standard and connection before the cutover began. Without it you are retiring a path on the strength of nobody having complained yet, which is how a quarterly process discovers the migration on its own schedule.
The two standards behave differently on logout. How do you handle that in a dual-standard estate?
Decide and document what the estate actually guarantees, rather than assuming the proxying identity provider will harmonise it. It can only forward what an upstream sent, so the guarantee is bounded by the weaker of the two paths for any given member. Treat the divergence as a selection and coexistence input; the mechanics of either standard's logout belong to that standard's own material.
A member arrives speaking WS-Federation Version 1.2. Does that break the plan?
No, but it adds a third termination path rather than a variant of an existing one. WS-Federation Version 1.2 is an OASIS Standard published in May 2009 and some estates still run it. The containment decision holds: terminate it at the same place and re-issue the same internal credential, record it as that member's standard in the member registry, and sequence its cutover like any other member's.
What is the strongest argument against the proxying identity provider approach?
It concentrates risk. One component now sits between every member and every application, so its availability is the federation's availability and its defects are everyone's. That is a real cost, and the answer is operational rather than architectural: treat it as tier-one, since the alternative — two standards reaching every application — spreads the same risk over far more code.

saying these in an interview costs you the question

Plans a single global cutover date for every member organisation
Lets both standards reach the applications instead of terminating them at one place
Assumes a proxying identity provider can supply attributes the upstream never sent
Moves the largest member first to get the hard case over with
Retires an old connection on a date rather than on zero traffic
Expects logout to behave identically across both standards

A clearing house must accept both SAML 2.0 and OpenID Connect logins from member organisations for years — how do you sequence it?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The decision that makes everything else tractable

Make the standard a property of the member, not of the estate

The dual-acceptance window

Which side moves first

What a proxying identity provider cannot do

What to instrument before you move anything

▾common follow-ups4 questions

▾red flags6 flags

The decision that makes everything else tractable

Make the standard a property of the member, not of the estate

The dual-acceptance window

Which side moves first

What a proxying identity provider cannot do

What to instrument before you move anything

answer

go deeper