SAML SSO for SAP Commerce: Storefront, Backoffice, and the Flows Between

Single sign-on requests arrive at commerce teams from two directions at once: the business wants customers (especially B2B users) logging in with their company or CIAM identities, and IT wants employees reaching Backoffice with corporate credentials instead of another password. Both are federation problems, both usually mean SAML somewhere in the chain, and both fail in the same handful of well-documented ways. This guide covers the concepts precisely, the commerce-specific wiring on both surfaces, and the caveats the CX Works federation material recorded from production scar tissue.

Vocabulary, Precisely#

SSO is the outcome: authenticate once, access many authorized resources without re-authenticating. Federation is the mechanism: a trust arrangement where a Service Provider (SP, the thing you access, here your storefront or Backoffice) accepts identity assertions from an Identity Provider (IdP, the thing that verified you: corporate Azure AD/Entra, a partner's IdP, or a CIAM layer). SAML 2.0 is the XML-and-signatures federation protocol that became the enterprise standard; OIDC is the newer token-based one built on OAuth 2.0. The rule of thumb the source material gives holds: SAML where enterprise IdPs and legacy expectations dominate (B2B partner logins, workforce SSO), OIDC for new consumer-facing and API-centric builds (next guide). Most estates run both, one per surface.

The Two Flows, and Why the Direction Matters#

SP-initiated (the default you should prefer): the user lands on your storefront, clicks login, the SP redirects to the IdP with an AuthnRequest, the IdP authenticates and posts back a signed assertion, session established. State is clean because your side started the conversation.

IdP-initiated: the user starts at the IdP's portal (a partner intranet listing "our supplier's order portal"), clicks the tile, and arrives at your Assertion Consumer Service endpoint carrying an unsolicited signed SAMLResponse plus an optional RelayState naming the deep-link target. The mechanics as the source lays them out: the IdP builds and signs the assertion, wraps it in an auto-submitting HTML form (SAMLResponse and RelayState as hidden fields), the browser POSTs it to your ACS, the SP validates the signature, creates the session, and redirects to the RelayState target.

IdP-initiated is common in B2B (procurement portals live at the buyer) and carries the caveats that fill support tickets:

• Existing sessions get trampled. The unsolicited assertion disregards any live session at the SP; a user logged in as one account arriving via a portal tile becomes another account without ceremony. Decide the policy (prompt, merge hint, silent replace) before a confused buyer decides it for you.
• RelayState is a fragile envelope: too long and redirects break against browser URL limits (the 404-after-login class of bug); unvalidated and it is an open-redirect vulnerability. Keep it short (an opaque key into server-side state beats a full URL) and allow-list the redirect domains.
• Domain topology bites: redirect-based auth flows resolve against configured canonical domains, and logins that work on the main domain fail on sibling domains that were never registered with the identity layer. Every domain your storefront answers on (the endpoint list from the web architecture guide) must be reflected in the SSO configuration's allowed domains.
• It is slower by construction: cross-domain redirects and form posts before first byte of the target page. Front-load that expectation with stakeholders comparing it to local login.

Commerce Surface One: Customer Login on the Storefront#

Composable storefront and OCC estates typically do not speak SAML directly from the SPA; the pattern is a broker: the storefront authenticates against an identity layer (CIAM such as SAP Customer Data Cloud, or any IdP-broker like Azure AD B2C or Keycloak) via OIDC, and that layer federates outward via SAML to the enterprise IdPs. This keeps the storefront on one modern protocol while the broker absorbs per-partner SAML variance (certificates, clock skew, attribute naming), which is exactly the variance you do not want in your storefront codebase.

Whatever the topology, the commerce-side work is identity mapping: the assertion's subject and attributes must resolve to a Customer (or B2B B2BCustomer with unit assignment, which is the just-in-time provisioning story the B2B identity guide covers in depth). Decide and document: which assertion attribute is the immutable key (never email alone in B2B; employees change addresses), what happens on first arrival (JIT-create versus reject-unknown), and which profile fields the IdP owns versus commerce owns thereafter.

Commerce Surface Two: Employees into Backoffice#

The platform ships the samlsinglesignon extension for exactly this: SAML SSO for the employee-facing applications (Backoffice, hAC-adjacent surfaces), with the commerce side acting as SP against your corporate IdP. The implementation notes that matter:

• Mapping is configurable from assertion attributes to user and user group, which is where the user management guide's role model meets federation: the IdP asserts who you are; the mapping decides you are productmanagergroup. Keep authorization mastered in commerce (groups) and authentication mastered in the IdP; splitting it any other way ends in audit findings.
• Local password login should be disabled or restricted for SSO-managed employee accounts once federation is proven, or you have two front doors and one alarm.
• The Backoffice endpoint is already IP-restricted (per the endpoint matrix); SSO complements, not replaces, that restriction. Defense in depth includes the case where the IdP itself is compromised.
• Break-glass access: one non-federated emergency admin, vaulted credentials, alerting on its use. IdP outages happen, and locking every administrator out of Backoffice during one converts an identity incident into a commerce incident.

Debugging Federation Like You Have Done It Before#

The source's troubleshooting list generalizes into a reliable sequence:

1. Decode the assertion. The SAMLResponse is base64 (sometimes deflated) XML; decode it and read the actual subject, attributes, audience, timestamps, and destination. Half of all federation tickets die right here when the assertion plainly shows the wrong NameID format or a stale audience URI.
2. Check clocks and validity windows: NotBefore/NotOnOrAfter violations from clock skew produce "sometimes fails" tickets. NTP on both sides; small skew tolerance configured.
3. Verify certificates deliberately: signing cert expiry at the IdP is a scheduled outage you can put in a calendar; do so, and monitor it like the TLS certs in the web architecture guide.
4. Walk the redirect chain with the browser network tab: CNAME/domain-prefix redirects, RelayState handling, ACS URL exactness (trailing slashes have ended careers). Compare against the allowed-domain configuration before touching code.
5. Then and only then read SP logs, because by now you know which side is lying.

SAML or OIDC: The Honest Table#

Federation projects fail on ambiguity, not cryptography: which attribute keys identity, who gets JIT-provisioned into what, which domains are in the trust map, what happens to existing sessions, who owns the certificate calendar. Write those five answers down before the first metadata exchange and the rest is configuration.