Cloud Migration Strategy and Execution Questions
Planning and executing a move to the cloud: the migration strategies (rehost, replatform, refactor, repurchase, retire, retain), legacy assessment, dependency mapping, cutover planning, and rollback. Covers phased migration roadmaps, workload modernization, risk management during cutover, and validating success post-migration. The end-to-end migration lifecycle, not steady-state operations.
Explain the roles of Identity Provider (IdP), Single Sign-On (SSO), federation, directory services, and attribute provisioning in an enterprise cloud identity architecture.
Sample Answer
Direct answer
An enterprise cloud identity architecture answers "who is this, and what can they reach" through five pieces working together, not five separate jobs. A directory service is the system of record holding identities and their attributes. An identity provider (IdP) is the service that actually checks who someone is and issues a signed assertion of that identity. Single sign-on (SSO) is the resulting user experience: log in once at the IdP, and every trusting application accepts that assertion without asking again. Federation extends that same trust across a completely separate organization's boundary, so a partner company's employee can be recognized without your directory ever holding their credentials. Attribute provisioning is the ongoing pipeline that keeps each downstream application's copy of a user's role, group, and status data synchronized with the directory that actually owns it.
Structured elaboration
Directory services. This is the central repository of identity data: users, their attributes, group memberships, and often devices. Its role in the architecture is to be the one place everything else references, instead of every application inventing and maintaining its own separate user list. Without a shared directory, a single person's access is scattered across as many disconnected records as there are applications, with no common source of truth for who they actually are or what they belong to.
Identity Provider (IdP). The IdP is the service responsible for verifying an identity, checking a password, a hardware security key, or a certificate, against the directory, and issuing a signed assertion that some application can trust. Its role is to separate "prove who you are" from every individual application that needs that proof, so applications trust an assertion instead of each implementing and securing its own login logic. Without a dedicated IdP, every application owns its own authentication code, which multiplies the number of places a credential-handling bug or misconfiguration can appear.
Single sign-on (SSO). SSO is the user-facing payoff of the IdP's work: authenticate once, and every application configured to trust that IdP accepts the resulting assertion without a second login prompt. Its role is to centralize where authentication controls like multi-factor authentication (MFA) and session timeout policy actually apply, instead of each application enforcing its own version, and to make offboarding a single action at the IdP rather than a separate revocation in every application. Without SSO, users tend toward separate, weaker, reused credentials per application, and losing access anywhere requires manually finding and revoking it everywhere.
Federation. Federation extends the same trust relationship across an organizational boundary: rather than a partner company needing accounts created and maintained in your own directory, your IdP trusts a signed assertion issued by the partner's own IdP (or vice versa), typically via a protocol like Security Assertion Markup Language (SAML) or OpenID Connect (OIDC). Its role is to let SSO-style access work between two separate companies, or between your company and a SaaS vendor, without either side sharing raw credentials or maintaining duplicate shadow accounts for the other's users. Without federation, external access either means standing up and manually maintaining a parallel account per external user, or the much worse alternative of sharing credentials directly.
Attribute provisioning. This is the pipeline, often built on a standard like the System for Cross-domain Identity Management (SCIM), that pushes a user's current attributes, role, department, group membership, active-or-disabled status, out from the directory to every application that needs that data to make its own authorization decisions. Its role is to keep those downstream copies fresh automatically, instead of relying on manual, per-application account administration. Without it, an application's picture of "what group is this user in" drifts stale over time, which can either grant access that should have been revoked already or deny access that should have already been extended, and every hire, role change, or departure needs someone to manually replicate the change into each connected application.
Worked example
Walk one employee's lifecycle through all five pieces at a fictional company, "Aster Corp":
| Component | What happens for this employee | Typical protocol |
|---|---|---|
| Directory service | Aster's directory creates the employee's record on day one, with department, manager, and initial group memberships | LDAP-style or a cloud directory API |
| Identity Provider (IdP) | The employee logs in each morning; the IdP checks their password plus a second factor and issues a signed assertion | SAML assertion or an OIDC ID token |
| Single sign-on (SSO) | That one login carries into the internal wiki, the expense system, and the code repository without a second prompt at any of them | The same assertion, trusted by each application |
| Attribute provisioning | Six months later the employee is promoted into a new department; the provisioning pipeline pushes that change from the directory into every connected application within the pipeline's normal sync window | SCIM |
| Federation | Aster's support vendor needs its own staff to view shared tickets; the vendor's employees authenticate against their own company's IdP, which Aster's system trusts via a federation agreement, so no vendor employee ever has an Aster-managed password | SAML or OIDC federation between the two IdPs |
The point the table makes end to end: the directory is the one place the truth lives, the IdP is the one place that truth gets checked, SSO is what the employee actually experiences as a result, provisioning is what keeps that truth current everywhere it has been copied to, and federation is what lets the same pattern work when the person authenticating belongs to a different organization entirely.
Trade-offs and pitfalls
SSO and federation are easy to use interchangeably, but they solve different problems: SSO is the single-organization experience of one login across many internal applications, while federation specifically crosses a trust boundary between two separate organizations. Conflating the two leads either to federating internal applications that never needed the extra protocol complexity, or to trying to get partner access working by sharing credentials directly instead of setting up real federation. The most common gap that looks harmless at small scale is skipping automated attribute provisioning and relying on someone in IT to update access by hand; this works fine in a pilot with a handful of users and quietly becomes a real security gap as headcount grows, since manual provisioning lag directly becomes an authorization gap during offboarding, exactly when speed matters most. Finally, letting more than one system claim to be the directory of record, say, a legacy system and a newer cloud directory both holding slightly different copies of the same users, recreates the exact "which record is actually true" problem the whole architecture exists to solve.
That is every published Cloud Migration Strategy and Execution question for Security Architect so far. Browse the other topics in this category, or practice this one interactively.