B2B Identity for Commerce: Delegated Administration, BYOI, and Just-in-Time Provisioning

B2C login is a solved problem with good defaults. B2B login is an organizational design problem: the unit of onboarding is a company, users arrive and leave by that company's HR processes you cannot see, access rights follow job functions you do not define, and the shared office@company.com mailbox is somebody's entire IT department. The CX Works CIAM-for-B2B series diagnosed the legacy state precisely (IT-driven onboarding taking days and arriving wrong, fragmented accounts per system, and ex-contractors holding live credentials years after leaving), and its prescriptions map directly onto how a SAP Commerce B2B storefront should handle identity. This guide translates them.

The Legacy Failure, Named#

Three costs recur wherever external-user management grew out of internal Active Directory habits:

• Slow and costly: manual onboarding through IT tickets, error-prone, measured in days per user, at partner-relationship expense.
• Poor experience: multiple accounts per user across your systems, no self-service, password resets by phone.
• Business risk: nobody can answer "who from partner X has access, and to what", and revocation depends on the partner remembering to tell you about leavers. (The source's author admits to still holding access from jobs left years prior; every B2B estate has those accounts.)

The modern architecture attacks all three with one principle: push identity lifecycle to the party that actually knows it. The partner organization knows its joiners and leavers; your job is to federate with that knowledge, not to replicate it badly.

Onboarding: Organizations First, Users Second#

Model onboarding as two distinct flows:

Organizations enter via self-registration (a prospective dealer applies through the storefront, triggering your approval workflow) or via backend processes (sales closes the contract, the account exists in ERP, a copy propagates to the identity layer and commerce). Either way, the commerce side lands in the B2B org model: a B2BUnit hierarchy carrying the business relationships (pricing, payment terms, cost centers) that the multi-site and store-specific pricing guides connect to actual buying behavior. The identity layer is not the master of organization data; it holds a working copy that facilitates login and administration.

Users then belong to organizations, and here delegated administration changes the economics: one or more partner-side administrators manage their own colleagues (invite by email or SMS, assign roles from the set you expose, deactivate leavers) through a self-service surface instead of your IT queue. Commerce's B2B roles (admins, approvers, buyers per unit) map onto exactly this delegation model. Compliance improves rather than suffers: the partner's admin knows Tuesday's leaver on Tuesday.

Login Identifiers: The Shared-Mailbox Problem#

The source's identifier analysis deserves preservation because every B2B project relitigates it:

• Email is the right default: always captured at invitation, self-service reset works, users remember it, B2C-familiar.
• Username should not be the primary identifier for new accounts (unassignable at invitation, forgettable, weak reset story). Its one legitimate role is migration compatibility: existing username-keyed users keep logging in while being nudged toward email.
• Phone/OTP solves the genuinely awkward case: small organizations where several people share one mailbox, which breaks email-as-unique-identifier. SMS one-time-password login gives each human their own identity with no password at all (and no reset flow), at the price of SMS provider costs.
• BYOI (below) dissolves the identifier question entirely for partners who federate: their corporate login is the identifier.
• Social login is marginal in B2B (LinkedIn niches exist); support account-linking if requirements demand, expect little.

The commerce-side echo: whatever the login identifier, the immutable key mapping the identity to the B2BCustomer must be the identity layer's unique ID, never the email string (the SAML and OIDC guides' rule, doubly binding where partners rename mailboxes).

BYOI: Their IdP, Your Storefront#

Bring Your Own Identity means the partner's employees authenticate to your commerce portal with their own corporate credentials: a per-organization SAML (or OIDC) trust between your identity layer and their IdP, configured through metadata exchange at the organization level. The assertion carries email, the unique identifier, name, and groups, and a predefined group-to-role mapping assigns commerce roles automatically.

When to invest per partner: BYOI shines for large partners (hundreds of users, real IT, existing leaver processes that de-provision AD and therefore, transitively, your storefront) and is overkill for the five-user dealer, who is better served by delegated admin plus email login. Run both; decide per organization size and capability, and record the decision in the partner onboarding runbook.

The governance won by BYOI is the quiet headline: revocation becomes the partner's HR process. The risk story from the legacy world (live credentials outliving employment) structurally disappears for federated partners.

JIT Provisioning: Accounts Created at the Moment of Truth#

Provisioning is how a user's record appears in each system needing one. Offline provisioning (batch files on a schedule) is the legacy pattern; Just-in-Time provisioning creates the local account at first authentication, from the assertion itself. The source's worked example is exactly the shape a commerce estate reuses: a portal user clicks through to an application, the IdP-initiated SAML assertion arrives carrying identity attributes plus role claims (editorRole, viewerRole in the sample), and the application creates-or-updates the user with those roles, no pre-registration, no nightly file.

Translated to commerce: first login of a federated partner user creates the B2BCustomer, attaches it to the right B2BUnit (from an organization claim or per-trust configuration), and assigns commerce user groups from the mapped role claims. Design decisions to write down before enabling it:

• Attribute contract per trust: which claims are required (reject assertions missing the unit or key), which are optional, and who owns updates on subsequent logins (re-sync roles at each login, or only at creation?). Re-sync-at-login is usually right: it makes the IdP's group change effective immediately, which is the point of federation.
• Default posture for the unmapped: an authenticated user with no recognizable role claim gets minimal read access or rejection, never a generous default.
• De-provisioning symmetry: JIT creates but never deletes; pair it with a staleness sweep (accounts with no login beyond a threshold get flagged to the partner admin) so the estate does not accumulate ghosts.

PBAC: Policies Over Role Explosion#

RBAC alone breeds role explosion (the source's phrase): more roles than users, each encoding one business exception. Policy-Based Access Control keeps roles few and expresses access as business-language policies combining who (roles/identities), what (assets), and when (conditions): "account managers can access account data", evaluated at request time via authorization APIs. For the commerce estate, PBAC-style thinking pairs naturally with the platform's own B2B permission machinery (order thresholds, approval workflows, budget permissions per unit): let the identity layer answer coarse access ("may this user reach the dealer portal at all"), and let commerce's B2B permissions govern commerce-native decisions ("may they place a 50k order without approval"). Splitting it the other way (business rules in identity policies, login rules in commerce) produces the two-systems-disagree incidents.

The Estate Checklist#

• Organization onboarding flow (self-service and backend) lands consistently in B2BUnit + identity layer
• Delegated administration live; your IT out of the routine user loop; partner admin duties in the contract
• Identifier policy: email default, phone/OTP for shared-mailbox partners, username only as migration bridge
• BYOI offered per partner with a size/capability threshold; trust setup runbooked; group-to-role mappings versioned
• JIT enabled with a written attribute contract, re-sync policy, minimal-default posture, and staleness sweeps
• Access model split documented: identity layer for access, commerce B2B permissions for commerce rules
• Quarterly access review per partner org, powered by the delegation and federation data you now actually have

B2B identity done well is invisible: the partner's new hire buys on day one with the login they already have, their leaver loses access without anyone emailing you, and your team stops being the help desk for other companies' staffing changes. Every hour invested in the trust and provisioning architecture above is repaid by the support queue that never forms.