Watch It Happen

Module 4 of 7 in the chapter Salesforce as the Service Provider: SAML, chapter 6 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: How do you see a single sign-on login as it happens, and how does each part of what Salesforce receives tie back to its setting?

Watch the back and forth

Everything in this chapter so far has been a picture. You can see the real thing in your own browser, and I’d recommend it to anyone learning single sign-on. It’s the fastest way to stop it feeling like magic.

You need a SAML tracer: a browser extension that watches the traffic and picks out the SAML messages. Salesforce itself suggests one when you need to inspect SAML traffic: the SAML Tracer plugin for Firefox, or Fiddler logs (S5). Here’s how I use it.

Open a private window, so no session from earlier gets in the way.
Open the tracer, and leave it running.
Go to the Salesforce org’s My Domain login page, and click the identity provider’s button.
Watch the address bar. It changes to the identity provider. In the tracer, one request gets a SAML tag: that’s the SAML request going out.
Sign in at the identity provider. What you see quickly is a redirect back to Salesforce, and then the home page. In the tracer, another SAML tag: the SAML response coming in.

Click either one, and the tracer decodes it for you, XML and all. That’s the whole of module 1, in your own browser.

The one that matters most

Of the two, the response is the one that unlocks Salesforce. It’s the one that needs to be most secure. Here it is as Salesforce receives it, trimmed. It’s chapter 4’s sample with two changes: the addresses are the ones Salesforce really uses, and the identity provider says Priya used MFA.

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="_3c3bd60b9ecebc800920…"
    InResponseTo="_2CAAAAYtjf8PNMDAwMDAw…"
    IssueInstant="2026-11-03T15:04:36Z"
    Destination="https://MyDomainName.my.salesforce.com?so=00Dx00000000001"
    Version="2.0">
  <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.example.com</saml2:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">…rsa-sha256…</ds:Signature>
  <saml2p:Status>
    <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </saml2p:Status>
  <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="_ec3f3208f463445cd2fa…" IssueInstant="2026-11-03T15:04:36Z" Version="2.0">
    <saml2:Issuer>https://idp.example.com</saml2:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">…rsa-sha256…</ds:Signature>
    <saml2:Subject>
      <saml2:NameID>E10442</saml2:NameID>
      <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml2:SubjectConfirmationData
            InResponseTo="_2CAAAAYtjf8PNMDAwMDAw…"
            NotOnOrAfter="2026-11-03T15:09:36Z"
            Recipient="https://MyDomainName.my.salesforce.com?so=00Dx00000000001"/>
      </saml2:SubjectConfirmation>
    </saml2:Subject>
    <saml2:Conditions NotBefore="2026-11-03T15:04:06Z" NotOnOrAfter="2026-11-03T15:09:36Z">
      <saml2:AudienceRestriction>
        <saml2:Audience>https://MyDomainName.my.salesforce.com</saml2:Audience>
      </saml2:AudienceRestriction>
    </saml2:Conditions>
    <saml2:AuthnStatement AuthnInstant="2026-11-03T15:04:36Z">
      <saml2:AuthnContext>
        <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract</saml2:AuthnContextClassRef>
      </saml2:AuthnContext>
    </saml2:AuthnStatement>
  </saml2:Assertion>
</saml2p:Response>

00Dx00000000001 stands for the org’s ID, in Salesforce’s own example (S3). E10442 is Priya’s employee number, which module 5 explains.

Each part, and the field that checks it

Now read it against module 3’s setting. Every part Salesforce checks has a field that tells it what to expect.

In the response	Salesforce checks it against	If it doesn’t match
`Destination` and `Recipient`	Its own address for answers, from the setting’s Endpoints, with the org ID after `?so=`	Recipient Mismatched
`Issuer`	Issuer	Issuer Mismatched
`Signature`	Identity Provider Certificate	Signature Invalid
`Audience`	Entity ID	Audience Invalid
`NotBefore`, `NotOnOrAfter`, `IssueInstant`	Salesforce’s own clock, and its window	Assertion Expired
`NameID`	SAML Identity Type and Location, then the user records	Subject Confirmation Error
The assertion’s `ID`	The IDs it has already used	Replay Detected

The right-hand column is the Login History errors from chapter 4, module 6. Now you can see which field each one points to.

Two signatures, and which one counts

Look closely and you’ll find two signatures: one on the envelope, the response, and one on the letter inside, the assertion. Does Salesforce need both?

It needs one. Salesforce “requires the identity provider to sign either the response body or the assertion, but it’s not necessary to sign both” (S2). It checks the response’s signature first; if that’s missing or invalid, it checks the assertion’s (S3). And it recommends that the identity provider signs both (S11). So set up the identity provider to sign both, with SHA-256, and you’re covered either way.

Why does the assertion’s signature matter so much? Because the assertion is the part that says who to log in as. Salesforce puts it plainly: even if an attacker catches the response in the browser and changes the outer envelope, the login “isn’t at risk as long as the assertion signature is intact” (S3).

How she signed in

The last part is newer in importance. The authentication context says how Priya proved who she is. Chapter 4’s sample said PasswordProtectedTransport: a password, over TLS. This one says MobileTwoFactorContract: a second factor, on her phone.

Since February 2026, that line decides something. For a SAML login from a device or browser Salesforce doesn’t recognize, Salesforce requires Device Activation, unless the assertion’s authentication context names a secure method. MobileTwoFactorContract, PublicKey, Smartcard and a few others count; a password alone doesn’t (S9). The identity provider can also say the same thing with an authentication method value such as mfa.

So the identity provider’s team has one more value to get right: send the authentication context that matches how people really signed in. For admins, Salesforce now requires phishing-resistant MFA, through single sign-on too; the Front Door chapter, module 2, has the rules.

It’s not magic

Watch a few logins with a tracer and something changes. It stops being a black box. It’s a request, a response, a few redirects, and a handful of values that have to match. It’s not magic. It’s technology, and it’s been designed against exactly the attacks we’ve talked about: someone changing a message on the way, and someone playing an old one back.

Watch it on video

In 2023 I made a video of exactly this: a login watched with a SAML tracer, and the request and the response opened up. The note under the video says what’s still right and what’s changed since.

STA 3.6 · Salesforce Security and Identity: Deep Dive into SAML Authentication · 12:24 · published 2023-09-26 · plays from YouTube when you click it · Watch on YouTube · More videos: Salesforce Identity & Access Videos

Still right

Watching a login with a SAML tracer: the request going out, the response coming back, the redirects in between.
What’s in the request and the response: the IDs, the issue time, the destination, the issuer, the signature, the subject, the time window, the recipient, the audience, the attributes.
Why the times matter: a narrow window against replay, so the clocks on both sides have to be right.
It’s not magic: it’s redirects and a signed message.

What’s changed

SHA-256, not SHA-1. The response in the video is signed with RSA-SHA1. The course uses SHA-256 throughout: Salesforce as an identity provider signs with a self-signed SHA-256 certificate by default (Enable Salesforce as a SAML Identity Provider (opens in a new tab), Salesforce Help, checked 2026-11-07).
Who holds what. The video speaks of a shared certificate. To be exact: the identity provider signs with its private key, and the service provider checks with the identity provider’s certificate (chapter 6, modules 3 and 4). Not a platform change.
How she signed in now matters. Since February 9, 2026, the assertion’s authentication context can decide whether a new device needs activation (Changes to Device Activation for SSO Logins (opens in a new tab), Salesforce Help, checked 2026-11-07).

What’s next

Module 5: the NameID, and how Salesforce finds the right user.

What an architect decides here

What the identity provider signs: the response and the assertion, with SHA-256.
What it sends as the authentication context, so MFA users aren’t stopped by Device Activation.
Who on the team can read a SAML trace, before the day you need one.

Explore

SAML Single Sign-On Flows (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
Salesforce SAML SSO: RelayState Parameter Returned as NULL from Identity Provider (IDP) (opens in a new tab) (Salesforce Help, published 2026-06-02; checked 2026-11-07), for the tracer
Changes to Device Activation for Single Sign-On (SSO) Logins (opens in a new tab) (Salesforce Help, updated 2026-02-24; checked 2026-11-07)