A partner asks your cloud platform to trust their own identity provider so their systems can call yours directly; how do you decide whether to accept?
answer
- a registration is a grant
- you inherit their administration
- blast radius decides before elegance
- compare against the credential you would issue
- reversibility: one change against a hunt
basics
~20 sDecide it as a delegation, not a configuration. Registering their issuer makes their identity administration part of your access decision, so weigh what the grant reaches, how reversible it is, and whether the caller could instead reach a boundary you operate.
solid answer
~50 sThe mechanism is easy and the decision is not. A registration says: anything that issuer signs, matching this condition, becomes this identity in our platform. Accepting it means whoever administers the partner's issuer can cause a signature you will believe, so you inherit their joiner process and their change control on the part of your access surface the grant reaches. Compare it honestly against the alternative, which is issuing *them* a credential of your own — a secret that then lives in an estate you cannot see and cannot inventory. Federation usually wins on **reversibility**: withdrawing a registration is one change on your side, whereas an issued credential must be hunted wherever it spread. It loses where the grant is broad and you have no way to observe how narrowly they scope their side. The third option is often best: put an interface you operate in front, so they authenticate to you and your component federates onward.
go deeper
Know that a platform can be told to trust an identity provider run by another company, and that doing so is a decision somebody senior signs off rather than a configuration detail.
Be able to say what the registration commits you to: whatever that outside issuer signs, matching your condition, becomes an identity with real grants inside your platform.
Compare it against the realistic alternative of issuing the partner a credential, and argue the reversibility difference — one registration removed against a value you must hunt down.
Answer with a standard, not a verdict: which outside issuers may be registered at all, the maximum grant for a partner-operated one, who approves, who owns the review, and what triggers revisiting it.
## What you are actually being asked for The request sounds like a piece of configuration and is a delegation. A registration of trust in an outside identity provider states, in effect: *anything this issuer signs that matches this condition becomes this identity inside our platform, with the grants that identity carries.* When the issuer is one you operate, the sentence is bounded by your own administration. When it belongs to a partner, the sentence delegates part of your access decision to people whose processes you did not write and cannot audit. That is not a reason to refuse. It is a reason to take the decision in the same room as a permission grant, with the same people. ## The comparison that actually decides it The alternative is almost never "they get nothing". It is usually that you issue them a credential of your own, which they then hold. Both options hand the partner access; they fail differently. | | You register their issuer | You issue them a credential | |---|---|---| | Who can cause access | Anyone who can make their issuer sign | Anyone who reaches the value in their estate | | Where the risk lives | Their identity administration | A secret you cannot see or inventory | | Withdrawing access | Remove one registration | Invalidate a value and hope you found every copy | | What you can observe | Calls that reach you | Calls that reach you | | What you must trust them to do | Scope and govern their signing | Store, rotate and contain a secret | The row that usually settles it is **reversibility**. Removing a registration is a single change on your side that stops new access immediately, while a credential you issued has to be invalidated and every consumer of it dealt with. That asymmetry favours federation for most long-lived partner integrations. ## The questions to ask before saying yes 1. **What does the grant reach?** Everything else is secondary to blast radius. A registration onto a narrow, read-only, single-dataset identity is a different decision from one onto an identity that can write or can reach other grants. 2. **Can the registration be narrowed to the specific caller you agreed on**, and would you notice if the partner's side changed such that something else matched? If the honest answer is no, the grant has to be small enough that you do not care. 3. **Who tells you when their issuer changes?** Re-keying, decommissioning, a merger, a change of provider on their side: none of these are visible to you unless the agreement makes them visible. Write the notification obligation down. 4. **What is the exit?** Name the person on your side who can remove the registration and the circumstances under which they would, before you create it. 5. **Could a boundary you operate take the call instead?** They authenticate to an interface you run, and your component — whose identity you do control — federates onward. This costs you a component to operate and converts an open-ended delegation into a defined one, which is usually the right trade when the grant is not trivially narrow. ## What this decision is not - **It is not a security ranking.** "Federation is more secure" is too coarse to decide with. It moves the risk from a secret you cannot supervise to an administration you cannot supervise, and which of those is worse depends entirely on the partner and the grant. - **It is not reversible by default.** Registrations accumulate. Without an owner and a review date, the one you add for a pilot outlives the pilot, the partnership and everyone who remembers why it exists. - **It is not a one-off.** The interesting version of this question is the *standard*: which outside issuers may be registered at all, who approves, what the maximum grant is for a partner-operated issuer, and where the list of live registrations is reviewed. A lead's job here is to make the second, fifth and twentieth request a decision someone has already framed, rather than twenty separate improvisations. ## A defensible answer Say yes where the grant is narrow, the registration can be pinned to the caller you agreed on, the partner is contractually obliged to tell you about changes to their issuer, and a named owner holds the review. Say no — and offer the front-door component — where the grant is broad, where you cannot pin the registration to one caller, or where nobody is willing to own it. And record which of those two answers you gave and why, because the next partner will ask the same question and the estate should not depend on who happened to answer.
- They cannot run an issuer you are willing to register. What is the alternative and what does it cost?Either issue them a credential of your own, scoped as narrowly as the grant allows and accepted as living in an estate you cannot see, or put an interface you operate in front so they authenticate to you and your side federates onward. The second costs a component to run and is usually the better trade whenever the grant is more than trivial.
- Why should adding an outside-issuer registration go through the same review as granting permissions?Because it is one. A registration says anything this issuer signs, matching this condition, becomes this identity here — a grant written somewhere else. Teams that scrutinise permission changes but add registrations casually have moved the control point without moving the control.
- What would make you revisit a registration you already approved?A change to what the granted identity can reach, a change of ownership or provider on the partner's side, the integration outliving the project that justified it, or the discovery that the registration matches more callers than the one you agreed on. Each of those should have an owner who is expected to notice it.
saying these in an interview costs you the question
- Treats a partner-operated issuer as equivalent to one you run
- Says federation is strictly safer, so no approval is needed
- Assumes the partner will tell you when their issuer changes
- Registers trust broadly and relies on the grant to save it
- Frames the choice as technical rather than as a delegation
- Creates the registration with no owner and no review date