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

> Why B2B login is an org problem: onboarding orgs versus users, delegated administration, login identifiers, bring-your-own-identity, JIT provisioning, and PBAC.

Source: https://www.commercecloudintegrations.com/guides/b2b-identity-and-jit-provisioning
Publisher: Commerce Cloud Integrations
Updated: 2026-08-11
Topics: security, architecture, integration, strategy, operations

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.