CCSP Cloud IAM Design: Federation, SSO, MFA, CASB and Secrets Management

Designing an identity and access management (IAM) solution for cloud applications means deciding who vouches for each user and workload, how applications check that proof, how strong the proof must be, how access is cut when it should end, and where the secrets, keys and certificates that hold the design together live. CCSP sub-domain 4.7 lists six skills:

• Federated identity: one organization's identity provider vouches for users to another organization's application.
• Identity providers (IdP): the system that authenticates users and issues the signed statement others trust.
• Single sign-on (SSO): one authentication at the IdP opens many applications.
• Multi-factor authentication (MFA): proof from more than one factor category, ideally phishing-resistant.
• Cloud access security broker (CASB): policy enforcement between users and the cloud services they use.
• Secrets, key and certificate management: the credentials applications and workloads use, kept out of code and rotated without outages.

The role the exam assumes is a cloud security professional advising on design. The right answer is usually the control that addresses the root cause at the right party and the right point in the flow: the application binds each tenant to its own IdP, the API checks that a token was meant for it, authorization stays with the relying party, and a leaked key is revoked before anything else.

Scope guards: account provisioning and deprovisioning with SCIM, break-glass accounts and customer key custody (BYOK/HYOK) are covered in the cloud security concepts lesson (1.3); envelope encryption, routine secret rotation and certificate expiry in the data security lesson (2.3); CASB shadow-IT discovery as a data-discovery tool in 2.4; API authentication patterns and mutual TLS between services in the verified secure software lesson (4.5). This lesson covers the application-side IAM design that ties them together.

Federated identity is an arrangement in which an application (the service provider or relying party) accepts an identity provider's signed statement about a user instead of holding that user's credentials itself. The identity provider is the only party that sees the password or authenticator. It authenticates the user and issues a signed assertion (SAML) or ID token (OpenID Connect); the relying party verifies the signature and grants a session.

How the trust is established

Trust is set up before any user signs in, by exchanging metadata: the IdP publishes its entity ID (issuer), endpoints and signing certificate; the relying party registers its own identifier and where assertions should be sent. Every assertion is signed with the IdP's private key, so the application verifies it with the signing certificate from that metadata. This matters because a SAML assertion usually travels through the user's browser (the POST and Redirect bindings; the Artifact binding instead fetches it over a back channel): TLS protects each hop, but only the IdP's signature proves who issued the assertion and that nobody altered it. The rule to hold onto: transport security and the relying party's own credentials say nothing about where a message came from; only the issuer's signing key does.

Trust is per issuer, and in multi-tenant apps per tenant

A multi-tenant SaaS application that lets each customer bring its own IdP must bind each tenant to the issuer and signing key of that tenant's IdP. If it accepts any correctly signed assertion from any federated IdP for any tenant, whoever controls one customer's IdP can mint identities that land in a different customer's workspace. Such an assertion passes every generic check, because it really is signed, addressed to the application and within its validity window. A valid signature proves who issued an assertion, not which tenant that issuer speaks for, so the fix is the trust mapping: tenant to issuer to key.

Federation topologies

• Hub and spoke: one IdP (often a cloud identity service fronting the corporate directory) federates with many applications; the common enterprise SSO pattern.
• Mesh / bilateral: each pair of organizations sets up its own trust; workable for a few partners, hard to manage at scale.
• Brokered: an identity broker or federation service (for example a research or education federation) relays trust between many IdPs and many relying parties.

Partner (B2B) federation: identity from them, authorization from you

When a supplier's or university's IdP signs users in to your application, it is trusted to say who the user is, not what they may do in your system. The relying party keeps authorization. Two design consequences follow:

• Map partner claims to an allowlist you define. An application that copies an incoming group or entitlement value directly into its own permission model has handed its authorization decisions to someone else's directory: whatever the partner writes, the application grants. Mapping each partner's values to the roles you decided that partner may hold keeps authorization inside your trust boundary. Controls that prove an assertion is authentic cannot help here, because the problem is an authentic assertion carrying a value you never meant to honour.
• Keep mapped attributes current. Just-in-time (JIT) provisioning creates the local account from the first assertion. If the application reads the attributes that decide access only when the account is first created, later changes at the source never reach it: someone reassigned to different work keeps the old permissions, however accurate their home directory is. Re-applying the claim-to-role mapping at every sign-in (or synchronizing attributes) fixes the cause; reviews that find the drift afterwards are detective, not preventive.

SAML 2.0 and OpenID Connect are authentication (SSO) protocols; OAuth 2.0 is a delegated authorization framework. The choice follows what the design needs: a sign-in to a web application, a sign-in plus API calls on the user's behalf, or an application acting with limited permission on someone else's data.

OAuth 2.0 delegation

OAuth exists so that a client application can get limited permission (expressed as scopes) to a resource without ever receiving the resource owner's password. The owner approves the scopes at the authorization server, which issues an access token the client presents to the API. The grant can be revoked without changing the password.

Grant types and current guidance

• Authorization code with PKCE: the recommended flow for user sign-in in web, native mobile and single-page apps. PKCE (Proof Key for Code Exchange) binds the code to the client instance that requested it, so an intercepted code is useless. The OAuth 2.0 Security Best Current Practice (RFC 9700) requires PKCE for public clients and recommends it for all.
• Implicit grant: returned tokens in the redirect URI; RFC 9700 says it should not be used, because tokens leak through browser history, referrers and logs. Code + PKCE replaced it.
• Resource owner password credentials: the client collects the user's password; RFC 9700 says it must not be used.
• Client credentials: machine-to-machine, no user present. The client authenticates as itself. Ideally it does so without a stored secret (see the workload identity section).

Public vs confidential clients

A confidential client (a server-side web application) can keep a client secret. A public client (a native mobile app or a browser single-page app) cannot: anything shipped to the device can be extracted. Public clients therefore rely on PKCE rather than a secret, and long sessions need extra care.

Long sessions for public clients: refresh token rotation

Keeping a single-page app user signed in for weeks needs a long-lived credential, which becomes the attacker's prize. RFC 9700 requires refresh tokens issued to public clients to be either sender-constrained (bound to a key the client holds, for example with DPoP) or rotated. With rotation, every refresh returns a new refresh token and invalidates the old one; if an old token is ever presented again, that reuse signals theft and the authorization server revokes the whole token family. The general rule: a long-lived credential on a public client must either be useless without a key the client holds, or be single-use so that theft shows up. Anything that is merely long-lived, hidden or encrypted on the device stays reusable by whoever copies it, and nobody notices.

An application must validate a token for the job it is being used for: an ID token proves to the client who signed in; an access token authorizes a call to an API. Using one in place of the other, or checking only that a token is authentic, opens confused-deputy flaws.

Access tokens are not proof of sign-in

An access token says what a client may do at an API; it says nothing about who is using this application, and it may have been issued to an entirely different client. Treating one as a login lets anyone who obtained a token through another app present it here. OpenID Connect added the ID token for exactly this reason. The client validates it for issuer, signature, audience = its own client ID, expiry and the nonce (when one was sent in the request); the audience check is what rejects a token minted for another client. Protecting how tokens are carried or stored does not change this: the flaw is in what the application accepts, not in how the token travels.

Every API checks audience and scope

Signature, issuer and expiry prove a token is authentic and current. They do not prove it is meant for this API or permits this action. Two more checks close the gaps:

• Audience: the API accepts only tokens whose audience names it, so a token a client legitimately obtained for one service cannot be carried to another service that trusts the same authorization server.
• Scopes (and any role or permission claims): the API compares the operation requested with what was actually delegated and refuses anything beyond it.

Rule of thumb: a valid signature proves who issued a token, not who it is for or what it allows. Each API must answer those two questions itself, from the token's own audience and scope claims.

The identity provider is the authoritative source of identity attributes for every federated application, so it decides how much personal data each relying party receives and it becomes the most valuable target in the architecture. Designing an IdP deployment means getting both right.

Types of identity provider

• Enterprise / workforce IdP: a corporate directory or an identity-as-a-service (IDaaS) platform that signs employees in to SaaS and internal apps.
• Customer IdP (CIAM): signs customers in to the organization's own applications, often with social sign-in options.
• Social or external IdPs: consumer accounts used as a sign-in option; convenient, but the organization controls neither their assurance level nor their account recovery.
• Partner IdPs: another organization's IdP trusted in B2B federation.

Release only the attributes each application needs

Every attribute (claim) an IdP releases becomes personal data the receiving provider processes and may store. An IdP configured to send the same broad attribute set to every connected application spreads that personal data to every provider in the federation, whether or not each one needs it. Per-relying-party attribute release policies limit each application to what it actually needs, which is what data-minimization principles require. Protecting assertions in transit is a separate control: it keeps the data from eavesdroppers, but the receiving application still gets all of it.

Subject identifiers: persistent, transient and pairwise

When an application must recognise returning users but must not receive any value it could match against the same person's identifiers at other applications, the IdP should release a pairwise identifier: the OpenID Connect pairwise subject type (OIDC Core section 8) or a SAML persistent name identifier generated per service provider. Correlation is a property of the identifier value itself; confidentiality in transit does not change what the application holds once the message is opened.

SSO: what it gives and what it concentrates

Single sign-on means the user authenticates once at the IdP, which vouches for them to every connected application. The direct benefit is central control: credential policy, MFA and account disabling happen in one place, so disabling one identity stops new sign-ins to every connected app. Users also manage one strong credential instead of many weak ones. Authorization still belongs to each application.

The trade-off is concentration risk: one compromised IdP account opens every application, and a compromised IdP administrator can change the federation itself. The controls with the greatest effect sit at the IdP: phishing-resistant MFA for users, and a small, tightly protected set of IdP administrators. Put the strongest control where the risk is concentrated rather than repeating weaker ones downstream. (On passwords, current NIST guidance, SP 800-63B-4, prohibits forcing periodic password changes when there is no evidence of compromise.) IdP availability is the other side of the concentration (recovery and outage planning sit in the BC/DR lesson, 3.5).

Disabling an account at the identity provider stops new sign-ins, but it does not end sessions applications have already created. The IdP is consulted when an application session starts; after that the application's own session cookie or token keeps the user in until it expires. SSO therefore has two layers of session, and the design must handle both.

The general rule: anything that acts at sign-in time, however strong, cannot reach a session that already exists (an assertion's validity window, for example, is checked only when the application session is created). Revocation and logout must be pushed to, and honoured by, the application.

Multi-factor authentication requires evidence from at least two different factor categories, so that stealing one kind of evidence is not enough:

• Something you know: password, passphrase, PIN, security-question answer.
• Something you have: a security key, smart card, phone with an authenticator app, hardware OTP token.
• Something you are: a biometric such as a fingerprint or face.

Some texts add location or behaviour; these are better treated as risk signals for conditional access than as independent factors. What defines MFA is categories, not the number of steps or devices: a password plus a security question is two things you know, a smart card plus a hardware OTP token is two things you have, and a fingerprint plus a face scan is two things you are. A FIDO2 security key unlocked with a fingerprint is genuinely two categories in one gesture: possession of the key, whose private key cannot be copied off it, plus inherence verified locally by the key.

Phishing-resistant versus relayable factors

An adversary-in-the-middle phishing proxy relays everything the user types or approves to the real site in real time and keeps the resulting session. Any factor the user can relay is defeated by it: passwords, time-based one-time codes, SMS codes and push approvals (even with number matching, because the user types the number shown on the proxied page). FIDO2 / WebAuthn authenticators, including passkeys and security keys, sign a challenge that includes the origin the browser is actually connected to. On the attacker's look-alike domain the authenticator produces no usable response, which is what makes them phishing-resistant.

Push fatigue (prompt bombing)

An attacker who already has a password can trigger push prompts repeatedly until a tired user approves one. Number matching blocks this: approval requires typing a number that appears only on the sign-in screen the user started, so a prompt the user did not initiate cannot be approved blindly. US CISA recommends number matching as an interim step for organizations that cannot yet deploy phishing-resistant MFA. Number matching is a setting in the authenticator users already have, so it can be turned on quickly; phishing-resistant MFA is the complete answer but takes longer to deploy.

Risk-based (adaptive or conditional) access decides how much proof to ask for at sign-in from signals such as device health, location, network and user behaviour. Step-up authentication asks for fresh, stronger proof at the moment a sensitive action is attempted, inside a session that is already established. They solve different problems.

In a step-up flow the application asks the IdP for a new authentication at a higher assurance level (in OpenID Connect, for example, by requesting a recent authentication or a specific authentication context) and continues only when it gets it. A step-up is only as strong as the factor it asks for: if the assurance needed at the moment of the action is phishing resistance, the step-up must use a FIDO2 / passkey authenticator, because a relayable code proves only that someone could type it. Step-up concentrates friction on the actions that warrant it; controls that apply at every sign-in, on every request or on a timer spread the same friction across all routine use.

A cloud access security broker (CASB) is a policy enforcement point placed between an organization's users and the cloud services they consume, applying the organization's security policies as those services are accessed. Its value is consistent policy across many SaaS applications the organization does not build or host. That separates it from controls that protect applications you run yourself or that secure particular credentials: a CASB sits on the path between your users and someone else's service.

The four functions (pillars)

Deployment modes

Choosing a mode comes down to three questions: must control happen in real time; are the apps sanctioned (so you control their sign-in) or not; and can you install or configure anything on the devices? Inline control over any destination, including services the organization never approved, needs a forward proxy, which in turn needs traffic steered from devices you manage, wherever they connect from. Inline control over your own sanctioned apps from devices you cannot touch needs a reverse proxy, inserted through the sign-in flow, which can allow some actions within a session and block others. Policy at the identity provider decides whether a session starts at all; it cannot shape what happens inside one. Work on data already stored or settings already in place is API mode. (Using CASB discovery as part of finding data is also covered in the data discovery lesson, 2.4.)

Secrets (passwords, API keys, tokens), cryptographic keys and certificates are the credentials an application and its workloads use. The design goals are: no secret stored where it can be copied, rotation without outages, and a fast response when one leaks.

Workload identity removes "secret zero"

A secrets vault only helps if the application can authenticate to the vault without another stored secret. Any stored bootstrap credential simply moves the problem: whoever can read it reaches every secret behind it, limiting it reduces the damage without removing the stored secret, and protecting it further always needs yet another secret. Platform workload identity (a managed or service identity issued and attested by the cloud platform) solves the bootstrap: the workload proves who it is with short-lived credentials the platform delivers, and nothing long-lived sits on disk. The same idea extends across organizations through workload identity federation: for machine-to-machine OAuth (client credentials grant, no user present), the job presents a short-lived signed token from its platform identity as its client assertion (JWT client authentication as in RFC 7523) instead of a client secret, so even a secret kept in a vault is unnecessary. Flows designed around a signed-in user do not fit a job that has no user.

Keep secrets out of code, images and deployment files

• Not in source code or repositories: use secret scanning to block commits.
• Not in container images: image layers are additive, so removing a file in a later build step hides it from the final filesystem but leaves it readable in the earlier layer.
• Not fixed at deploy time: a value in a manifest or environment variable, encrypted or not, only changes when the deployment changes, and manifests in source control expose it.
• Retrieved at runtime from the secrets manager, and re-read when it rotates, so rotation needs no rebuild or redeploy. (Rotation schedules and dynamic per-service database credentials are covered in the data security lesson, 2.3.)

When a secret leaks, revoke first

Public repositories are scanned for credentials by automated tools within minutes, so a secret that has been public must be treated as known to others; cleaning up history afterwards cannot recall copies. The order is: revoke and replace the credential so it stops working; then review activity logs for misuse; then purge it from history; then add preventive controls such as pre-commit secret scanning. Every step is right; only revocation stops ongoing harm.

Application key design

• Per-tenant keys and crypto-shredding. Crypto-shredding makes data unrecoverable by destroying the key, which also covers backups and replicas that are hard to find. It can only target what a key exclusively protects, so a SaaS provider that must erase one tenant's data cryptographically needs a dedicated key per tenant (often a tenant key-encryption key wrapping that tenant's data keys). Isolation that is not cryptographic, or a key shared with other tenants, cannot be destroyed for one tenant alone.
• Signing-key rotation with overlap. When an issuer signs session or ID tokens that many APIs verify, rotate by publishing both the old and new public keys, each labelled with a key ID (kid), in a key set (the JWKS pattern OpenID Connect uses). New tokens are signed with the new key; verifiers pick the key by ID; old tokens stay valid until they expire, then the old key is retired. No user is logged out. Asymmetric signing matters here too: verifiers hold only public keys, so none of them can mint tokens.
• Key separation: separate keys for signing and for encryption, and per environment, so compromise of one does not expose the others. Keys belong in the provider's key management service or an HSM (customer key custody models are covered in lesson 1.3).

Certificate design

• Private CA for internal names. CA/Browser Forum Baseline Requirements stopped publicly trusted CAs issuing certificates for internal names (such as private top-level domains like .internal) years ago, and every publicly trusted certificate is recorded in public Certificate Transparency logs, which would reveal internal service names. For internal microservices, a private CA whose root is distributed only to the company's workloads gives one trust anchor, automated issuance and no public exposure. The point of the CA is the shared trust anchor: every service validates every other against one root.
• CAA records prevent; CT monitoring detects. A DNS CAA record (RFC 8659) names the CAs allowed to issue for a domain, and publicly trusted CAs must check it before issuing, so unauthorized issuance is stopped. Monitoring CT logs for your domains is the matching detective control. Preventing issuance has to happen at the CA, which is why the control is a record the CA is obliged to check.
• Automate short-lived issuance. Public TLS certificate lifetimes are being cut in stages by the CA/Browser Forum, so issuance and renewal should be automated (for example with the ACME protocol) and inventoried; manual renewal is where expiry outages come from.