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.

The self-registration half has a shipped shape worth reading before you design your own. The secureportaladdon add-on models an applying company as a B2BRegistration (company name, contact details, a country, a rejectReason for the refusals) and runs the approval through the B2BRegistrationProcess business process, with CMSSecurePortalRestriction keeping portal content away from visitors who have not been approved yet. It is an accelerator add-on, so on a composable storefront you reuse the state model and rebuild the pages, but the states are the ones you would have invented anyway.

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 map onto exactly this delegation model, and they are four ordinary user groups rather than an abstraction: b2badmingroup, b2bmanagergroup, b2bapprovergroup, and b2bcustomergroup, declared as constants in de.hybris.platform.b2b.constants.B2BConstants. A partner-side administrator is a B2BCustomer in b2badmingroup whose reach is bounded by the B2BUnit branch they sit in, which B2BUnitService resolves (getBranch, getAllParents) on every permission question. 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.

State one platform boundary plainly here, because projects meet it late and expensively: the samlsinglesignon extension federates the employee-facing applications (Backoffice and the assisted service surfaces), not storefront customers. BYOI for B2BCustomer accounts means either a customer identity layer in front of commerce (SAP Customer Data Cloud is the portfolio answer) or your own service provider integration feeding the storefront through the token bridge the OIDC guide describes. Budget it as an integration with a per-partner trust to operate, not as a configuration flag.

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 the B2B user groups from the mapped role claims. Two writes carry the whole flow, B2BUnitService.addMember for the unit attachment and group membership for the role, which is also the shortest test you can write against a new trust. 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, and that machinery is typed rather than notional: the b2bapprovalprocess extension defines B2BPermission with B2BOrderThresholdPermission (a threshold plus a currency) and B2BOrderThresholdTimespanPermission beneath it, while spend limits ride B2BBudget records attached to a B2BCostCenter under the unit. So let the identity layer answer coarse access ("may this user reach the dealer portal at all"), and let those 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.