SAML 2.0 for the SA interview

Why SAML still matters in 2026

If you are interviewing for a systems analyst role at any company larger than a few hundred employees, SAML 2.0 will come up. It is the dominant enterprise SSO protocol, baked into AD FS, Okta, Ping Identity, and Keycloak. New consumer products skip it for OIDC, but the moment your roadmap touches a Fortune 500 customer or a regulated industry, SAML is back on the table. The interviewer is not testing XML trivia; they want to know if you can write a sane integration spec without breaking the customer's IdP.

The pain that gets analysts in trouble is subtle. A junior SA writes a ticket that says "support SSO via corporate IdP" and lets engineering pick the protocol. Engineering picks OIDC because it is more modern. Two sprints later, the customer's IT team says their AD FS only speaks SAML, and the integration gets rebuilt from scratch — a six-week rework that one clarifying question would have prevented.

OIDC is gradually eating SAML's lunch, but enterprise adoption cycles are measured in decades. Expect SAML to be a live integration target for the rest of your career.

Roles in a SAML flow

There are three entities, and the names are not optional jargon — the interviewer will use them and expect you to keep up.

The IdP (Identity Provider) owns the user's identity and credentials. Examples: Microsoft Entra ID, Okta, Auth0, Keycloak, on-prem AD FS. The IdP authenticates the user and issues a signed statement about who they are.

The SP (Service Provider) is the application that wants to authenticate the user but does not store credentials. Your Notion, your Linear, your internal admin tool — anything an enterprise customer logs into via SSO. The SP delegates authentication to the IdP and trusts the signed response.

The User is the human in the browser. In SAML, the browser is the courier that carries XML payloads between SP and IdP. There is no direct back-channel between SP and IdP in the most common bindings — everything goes through the user's browser, which is one of the protocol's quirks.

[User] ---> [SP]   "redirect to IdP"   ---> [IdP]
                                              |
                                       [user authenticates]
                                              |
[User] <--- [SP]   "SAML Response"     <--- [IdP]

Trust between SP and IdP is established out-of-band through metadata exchange. Each side publishes an XML metadata file containing its entity ID, endpoints, and X.509 certificates. The other side imports it. This is a manual setup step between two ops teams — and it is exactly the step that breaks during certificate rotation, which we will get to in the pitfalls.

The SP-initiated authentication flow

There are two flow variants. SP-initiated is the default and the safer choice; IdP-initiated is convenient for portal-style launchers but opens attack surface.

In the SP-initiated flow, the user hits a protected URL, the SP notices there is no session, and the choreography begins. The SP builds an AuthnRequest — a signed XML document containing the SP's entity ID, the requested NameID format, and a unique request ID. It redirects the browser to the IdP, passing the request via either query string or POST.

The IdP receives the AuthnRequest, prompts the user to log in (or reuses an existing session), then constructs a SAML Response containing an Assertion. The Response is signed with the IdP's private key. The IdP redirects the browser back to the SP's Assertion Consumer Service (ACS) endpoint via HTTP POST, carrying the signed Response in a form field.

The SP receives the POST, validates the signature using the IdP's public certificate from metadata, checks the timing and audience conditions, extracts the user attributes, and creates a local session. The user is redirected to the originally requested URL, now authenticated.

Artifact binding is rare in greenfield integrations. If asked "which binding for the response?", the safe answer is HTTP-POST — redirect URLs cannot fit a signed assertion under most browser URL length limits.

IdP-initiated SSO skips the AuthnRequest. The user lands on the IdP portal, clicks an app tile, and the IdP fires off an unsolicited SAML Response to the SP's ACS. The protocol allows it, but the SP has no pending request to match against. Without a properly bound RelayState, the SP cannot verify intent — which is the door that response-injection attacks walk through.

Assertion structure and signature checks

The Assertion is the meat. It is an XML element wrapped inside the SAML Response, and it carries everything the SP needs to identify the user.

<saml:Assertion>
  <saml:Subject>
    <saml:NameID>user-12345@example.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-05-22T10:00:00Z"
                   NotOnOrAfter="2026-05-22T10:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://sp.example.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>jane@example.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="department">
      <saml:AttributeValue>Engineering</saml:Attribute>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

The signature is XML Digital Signature (XML-DSig). The IdP signs either the entire Response, the Assertion itself, or both. The SP validates using the public certificate it imported from the IdP's metadata. If the signature fails, drop the request — do not log the user in with a "warning".

The InResponseTo check is the one most teams forget. It binds the response to a specific outstanding request — without it, an attacker who captures an old response can replay it against a different user's session. Keep request IDs in a short-lived store (Redis with a 5-minute TTL works) and reject responses whose InResponseTo is unknown.

SAML vs OIDC

This table is the one to memorize. If you can reproduce it from memory in an interview, you have demonstrated 80% of what the question is checking.

The short heuristic: if the IdP is a corporate identity store and the SP is a browser-based app, pick SAML or accept it as a requirement. If the SP is a mobile app, a SPA with API access needs, or a B2C product, pick OIDC. Most modern IdPs speak both, so the question is usually about what the customer's existing IdP supports, not what is technically newer.

What to put in the integration spec

When you write the SA spec for a SAML integration, the engineering team needs answers to a handful of questions. Skip any of these and they will come back asking — which is fine, but it slows the ticket down and signals junior work to the reviewer.

SAML Integration Spec

Roles
  IdP: corp.example.com/adfs (Microsoft AD FS)
  SP: app.example.com
  SP entity_id: https://app.example.com/saml/metadata

Bindings
  AuthnRequest: HTTP-Redirect
  Response: HTTP-POST to https://app.example.com/saml/acs

Identifiers and attributes
  NameID format: emailAddress
  Required attributes: email, given_name, family_name, department
  Optional attributes: manager_email, employee_id

Security
  Signature algorithm: SHA-256
  Request signing: yes
  Response signing: required
  Assertion encryption: optional (negotiate with customer)

Lifecycle
  Metadata refresh: SP polls IdP metadata URL daily
  Certificate rotation: IdP notifies SP ops 30 days before expiry
  Single Logout (SLO): supported via HTTP-Redirect

The two fields people forget are attribute mapping and certificate rotation. Attribute mapping is where SAML attribute names get translated into your internal user model — department in SAML might map to team in your database, and the spec needs to say so explicitly. Certificate rotation is the operational landmine; certificates expire on a 1–3 year cadence, and unless the spec defines a notification process, your integration silently breaks one Tuesday morning two years from now.

Common pitfalls

The most catastrophic mistake is failing to validate the signature. Every few years a vulnerability disclosure surfaces a major SAML library that accepted unsigned or weakly-signed assertions under some edge case. In the spec, state the rule explicitly: signature must be cryptographically valid against the trusted IdP certificate, and unsigned responses must be rejected without exception.

Equally common is skipping Audience validation. The AudienceRestriction element says which SP the assertion was issued for. If you do not check that the value matches your SP's entity ID, a response intended for another SP sharing the same IdP can be replayed against yours. The fix is one string comparison; the impact of skipping it is full account takeover.

Ignoring the NotOnOrAfter timestamp opens the door to replay attacks. Assertions are typically valid for a few minutes, but if the SP does not enforce the window, a captured response can be reused indefinitely. Always check NotBefore <= now <= NotOnOrAfter with a small clock skew tolerance — 60 seconds is standard, more than 5 minutes is reckless.

Using SHA-1 for signatures is a hangover from older deployments. SHA-1 has been broken for signing purposes for years; modern IdPs default to SHA-256 and SPs should reject SHA-1 outright. If you find SHA-1 in a legacy spec, flag it as your answer to "what would you change about this design?".

SAML on a mobile native app is a misuse of the protocol. SAML assumes a browser as the courier; native apps need OIDC with PKCE. If a customer insists, the right answer is an OIDC bridge that federates back to their SAML IdP — most identity platforms do this transparently.

IdP-initiated SSO without RelayState is the textbook response-injection vulnerability. Either disable the flow or require a signed and validated RelayState that binds the response to a specific landing page. The convenience of "click a tile, land on the app" is not worth the attack surface in B2B contexts.

Finally, omitting certificate rotation from the spec is the slow-motion pitfall. The integration works for 18 months, then a Saturday-morning page wakes someone up because the IdP's signing cert rotated and the SP is still trusting the old one. Spec the notification window, the cutover test, and a fallback path.

Related reading

• OAuth for systems analyst interview
• JWT for systems analyst interview
• JWT pitfalls for systems analyst interview
• OWASP Top 10 for systems analyst interview
• RBAC vs ABAC for systems analyst interview
• Authentication vs authorization for systems analyst interview

If you want to drill SA topics like SAML, OIDC, and SSO design daily, NAILDD is launching with structured problem sets across this pattern.

FAQ

Is SAML dead?

In greenfield consumer products, effectively yes — nobody is starting a new B2C app with SAML in 2026. But in enterprise, it is the opposite story. AD FS, Okta classic tenants, and on-prem identity systems run SAML as the default protocol, and the migration cost to OIDC is large enough that most organizations have not bothered. Expect SAML to remain a hard requirement for enterprise customers for at least another decade.

Can SAML and OIDC coexist in the same IdP?

Yes, and most modern IdPs (Okta, Keycloak, Auth0, Microsoft Entra) support both natively. A common pattern is SAML for the enterprise's own employees connecting to internal apps, plus OIDC for external partners and customers. The IdP handles the protocol translation, and your SP can advertise both endpoints in its metadata.

What is SCIM and how does it relate to SAML?

SCIM (System for Cross-domain Identity Management) is a separate REST-based standard for provisioning users, not authenticating them. SAML answers "is this user who they claim to be right now?". SCIM answers "create, update, or deactivate this account in advance". They work together: SCIM syncs the SP's directory with the IdP, SAML handles the login. Enterprise integration specs usually include both.

Does the IdP need to know about every SP?

Yes. Every SP must be registered as an "application" or "relying party" in the IdP, with its entity ID, ACS endpoint, and trusted certificate. In a large enterprise this catalog can hold hundreds of entries. From the SA side, your spec must include the SP's metadata file or URL so the customer's IT team can register it.

What about WS-Federation?

WS-Federation is a Microsoft-originated SSO standard that predates broad SAML 2.0 adoption. Functionally similar, different token format. In modern deployments it is almost entirely superseded by SAML 2.0 and OIDC. You will only meet WS-Fed in legacy AD FS environments, and the right answer in an interview is "I would migrate it to SAML or OIDC during the next refresh cycle".

Is this article official documentation?

No. It is structured around the OASIS SAML 2.0 specification, vendor docs from AD FS, Okta, and Keycloak, and common implementation patterns in enterprise SSO. Treat it as interview prep, not a normative reference — for compliance work, read the OASIS spec directly.