Skip to main content
Talk to an expert
LDAP logo

LDAP integration for ecommerce identity and access

LDAP login flows integrated with trade account rules LDAP integrates with your commerce platforms so users authenticate once against the corporate directory and permissions flow from group membership. iWeb handles customer account linking, cost-centre rules, immediate deprovisioning and observability so that access governance stays in step with your directory. Works with Adobe Commerce, Magento Open Source, Shopify Plus, BigCommerce and other storefronts.

Also searched as: SSO, single sign on, identity provider, SAML, OAuth, LDAP, customer accounts.

LDAPiWeb integration layeryour storefront
Talk to an expertSee the estate map ↓
Works with - Adobe Commerce · Magento Open Source · Shopify Plus · BigCommerce · Other storefronts
On this pageGet a brief reviewed
01 · What you get

What a LDAP integration gives you.

Single sign-on across channels

Users log in once to LDAP and gain access to the storefront, trade portal, and internal systems without re-entering credentials. Session state is consistent across all touchpoints.

Permissions flow from the directory

Trade-account permissions, approval workflows, and cost-centre rules are driven by LDAP group membership so that changes in the directory propagate without manual portal administration.

Immediate access revocation on termination

When employees resign or contractors end, their LDAP record is disabled and all commerce platform access, trade portals and linked customer accounts are locked immediately.

Unified customer and employee identity

Trade customers, employees and call-centre staff who exist in LDAP are also recognized in the ecommerce system. Orders, accounts and support history are visible to staff without account-linking gaps.

Compliance and audit trails

Login events, permission changes and session terminations are logged and traceable so that access governance and segregation-of-duties rules can be demonstrated to auditors.

02 · When it's worth it

Where a LDAP integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Trade portal login against corporate Active Directory
Storefront SSO using LDAP as the identity source
Staff and call-centre user provisioning and deprovisioning
Group-to-role mapping so directory groups control commerce permissions
Customer account linking between LDAP and ecommerce systems
Multi-site login where branch, trade and online share a single identity
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

No native customer account linking

LDAP authentication alone does not map corporate users to ecommerce customer records (accounts, orders, addresses, credit). Manual customer master data syndication or a separate identity-mapping layer is needed.

Trade pricing and approval rules are separate

LDAP provides authentication and group membership; it does not carry cost-centre, spending limits, contract pricing or approval thresholds. These must be maintained separately in the ERP or OMS and synced in parallel.

No built-in session observability across systems

LDAP does not log failed logins, permission mismatches or orphaned sessions across multiple storefronts. Session state and exception handling must be instrumented at the commerce or middleware layer.

Password policy and MFA enforcement varies

LDAP supports passwords and some MFA schemes, but commerce platforms may have different MFA requirements (TOTP, email codes, hardware tokens). Policy conflicts require customization.

No automatic deprovisioning of abandoned sessions

When a user is disabled in LDAP, active sessions on the storefront may persist until the cache expires. Immediate logout and session termination require integration logic.

04 · The real work

Access governance fails silently when deprovisioning is delayed or when account-linking mismatches leave trade customers locked out. The integration must make permission changes and session termination observable.

05 · Where it sits

Where this integration sits in your estate.

LDAP holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.

Built for your platform, not a specific one. LDAP integrates with any ecommerce core through the same contract.

System of record
Source / owner
LDAP
Identity and access control layer, directory-driven authentication source
  • User identity records and profile data
  • Group membership and directory roles
  • Authentication credentials (masked in LDAP)
  • Cost-centre and organizational attributes
  • User enabled/disabled status
iWeb integration layer
Customer-facing commerce
Commerce platform
Adobe CommerceMagento Open SourceShopify PlusBigCommerceOther storefronts
  • Session tokens and active-session state
  • Derived commerce roles and permissions
  • Account linking between LDAP user and ecommerce customer
  • Commerce-specific user preferences and settings
  • Trade-account access and customer-record visibility
Connected neighbours
Integration layer
ERP
Supplies customer master, credit limits, approval thresholds and trade-specific pricing rules that enforce LDAP permissions
Integration layer
OMS
Uses LDAP-derived permissions for order approval workflows and trade-account routing rules
Integration layer
CRM
Receives LDAP user identity to recognize support staff and enables customer-identity linking across channels
Integration layer
Secrets vault
Manages LDAP bind credentials, TLS certificates and rotation schedules
Integration layer
Security monitoring
Collects login failures, permission changes and session terminations for audit and threat detection
Two-way sync where relevant
06 · Surrounding systems

Systems this integration usually sits next to.

Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.

Ecommerce platforms (examples)
  • Adobe Commerce
  • Magento Open Source
  • Shopify Plus
  • BigCommerce
  • Other storefronts
Surrounding systems (examples)
  • Active Directory / LDAP directory
  • ERP (for customer master and approval rules)
  • OMS (for trade-account order routing and approval)
  • CRM (for customer identity and support access)
  • Secrets vault (for credential management)
  • Security monitoring and audit logging
  • Email and notification systems
  • Session cache or Redis
Not sure?

Not sure if this works with your stack?

Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.

07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into COMMERCE
←From COMMERCE
↔BOTH WAYS
Authentication and user provisioning: When a user logs in to the storefront or trade portal, LDAP credentials are validated and the user record (email, full name, groups, cost centre) is provisioned or updated in the commerce platform
Groups map to commerce roles and permissions.
Group and permission changes: When directory groups change (e.g
a user is promoted or joins a department), group membership is read from LDAP and commerce permissions are updated without requiring a new login. Trade-account spending limits and approval workflows are updated accordingly.
Customer account linking: Trade customers are matched between LDAP (as the corporate directory) and the ecommerce platform (as the customer record)
Account details, credit limits and customer classification flow both directions so that online and offline identities align.
Deprovisioning and access revocation: When a user is removed from LDAP (resignation, contract end), their access to the commerce platform, trade portal and any linked accounts is revoked
Abandoned sessions are terminated and orders become read-only.
Session and token validation: LDAP tokens or assertions refresh cached group membership and ensure that permission checks reflect the current directory state
Session timeouts are applied consistently across storefronts and internal systems.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Design LDAP authentication flows

    iWeb maps LDAP bind requests, group queries and token refresh cycles into the commerce platform so that users authenticate against the directory without the platform storing passwords.

  2. 02
    Build customer account linking logic

    iWeb matches LDAP user records to ecommerce customers using email, employee ID or cost-centre rules so that online and offline identities merge. Trade-account details flow to the commerce platform.

  3. 03
    Synchronize permissions and cost-centre rules

    iWeb reads LDAP groups and maps them to commerce roles, approval workflows and spending limits. Permission changes propagate without requiring a re-login or manual portal administration.

  4. 04
    Implement deprovisioning and session handling

    iWeb builds logic to detect disabled LDAP accounts and immediately revoke commerce platform access, terminate active sessions and lock trade-account records.

  5. 05
    Monitor and troubleshoot access issues

    iWeb instruments LDAP bind failures, permission mismatches, account-linking gaps and session termination so that access issues are surfaced and resolved before they impact users.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataUser directory and identity records
Source / ownerLDAP / Active Directory
Maintained byIT / Directory administrators
NotesCommerce platform queries LDAP on login and permission refresh but does not modify directory records. User profile changes are mastered in LDAP.
DataGroup membership and roles
Source / ownerLDAP / Active Directory
Maintained byIT / Directory administrators
NotesCommerce platform reads groups and maps them to commerce roles (e.g. approver, buyer, admin). Group changes in LDAP propagate via sync job.
DataCommerce account records and permissions on-platform
Source / ownerCommerce platform
Maintained byCommerce administrators
NotesThe commerce system holds the derived permission state (roles, approval limits, cost-centre rules) that flows from LDAP groups. This is a shadow of directory truth.
DataSession tokens and active-session state
Source / ownerCommerce platform
Maintained byCommerce platform session handler
NotesToken lifecycle, refresh, expiry and termination are managed by the commerce platform. LDAP deprovisioning events trigger session revocation.
DataTrade-customer account linking and addresses
Source / ownerCommerce platform (linked to ERP customer master)
Maintained byCommerce and ERP administrators
NotesThe commerce platform holds the link between LDAP identity and ecommerce customer record. ERP owns the underlying customer master (credit limit, pricing, account type).
DataLogin events, permission changes and session logs
Source / ownerIntegration logging and security monitoring
Maintained byiWeb integration layer and IT security team
NotesLDAP bind attempts, group-sync events and session terminations are logged centrally for audit, troubleshooting and compliance.
DataIntegration configuration and credential management
Source / ownerSecrets vault or configuration management
Maintained byIT and iWeb operations
NotesLDAP bind credentials, API keys and configuration changes are stored in a secrets management system and rotated on a schedule.
10 · Experienced integrator

Built LDAP identity integrations before

iWeb has designed and delivered LDAP authentication and account-linking integrations across multiple commerce platforms. We understand the mechanics of directory queries, group-to-role mapping, session handling and deprovisioning logic.

iWeb designs LDAP authentication flows so that login happens against the directory, not the commerce platform, reducing credential sprawl.
iWeb implements customer account linking so that trade customers authenticated via LDAP see their linked ecommerce account without re-login.
iWeb builds group-to-role mappings that stay synchronized when LDAP groups change, so permissions flow without manual portal administration.
iWeb instruments deprovisioning and session termination so that disabled users are locked out immediately, not after cache expiry.
iWeb integrates LDAP with OMS, ERP and CRM so that user permissions, trade-account rules and approval workflows reflect the authoritative directory state.
11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Verify LDAP bind succeeds with valid and invalid credentials and that connection failures are logged clearly.
Confirm that group membership is read from LDAP on login and that group-to-permission mapping is applied correctly.
Test that a disabled LDAP user cannot log in and that any active sessions are terminated within the configured timeout.
Validate that trade-customer account linking works for both email-based and employee-ID-based matching.
Confirm that LDAP bind credential rotation does not break authentication and that the old credential is revoked cleanly.
Check that failed login attempts, permission denials and session terminations are logged with timestamps and user identifiers.
Test multi-forest failover and confirm that users in either forest can authenticate without specifying a forest name.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Stale session cache locks out recently enabled users

If the commerce platform caches LDAP group membership for too long, a user who is added to a trade group in the directory may not see new permissions until the cache expires, breaking urgent approvals.

Disabled user still sees active session on storefront

LDAP deprovisioning does not automatically log out active sessions. If a resigning employee logs in before the deprovisioning job runs, they may have hours of access after leaving the company.

Account-linking mismatch leaves orders orphaned

If the matching logic between LDAP user records and ecommerce customers is fragile (e.g. email-based matching when emails change), a trade customer's online account may become unreachable from their LDAP identity or support staff may not see their history.

Permission denials are silent or buried in logs

When a user's LDAP group membership changes and they are removed from a trade-account approval role, they may attempt to approve an order and fail without understanding why. Audit trails and user-facing messaging must be explicit.

LDAP bind credential rotation breaks authentication

The service account used by the commerce platform to query LDAP may have a rotated password that is not updated in the platform configuration. Authentication stops working until the credential is manually refreshed.

Multi-directory forest logic is unowned

If the enterprise uses multiple LDAP forests (separate directory instances for acquisitions or geographies), the integration may not query all forests consistently. Users in one forest may not authenticate while others do.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about LDAP integrations.

How does LDAP authentication work in the commerce platform?

When a user enters their username and password on the login page, the commerce platform connects to LDAP using a bind request. If the credentials are valid, LDAP returns the user's profile (email, full name, groups, cost centre). The commerce platform then creates or updates a session and maps the user's groups to commerce roles.

How do LDAP groups map to commerce permissions?

iWeb defines a mapping table that associates LDAP group names (e.g. SALES_APPROVERS, FINANCE_TEAM) with commerce roles and permissions (e.g. can approve orders up to £10,000, can view invoices). When a user logs in, their LDAP groups are read and commerce permissions are set accordingly. The mapping must be maintained when groups are created or renamed.

What happens when a user's LDAP group membership changes?

A scheduled sync job queries LDAP at regular intervals (e.g. every 15 minutes) and reads all group memberships. If a user is added to or removed from a group, the commerce platform updates their permissions. Users may need to log out and log back in to see the new permissions, or permissions may refresh silently at the next token refresh.

How are disabled LDAP users locked out of the commerce platform?

When a user is disabled in LDAP (e.g. on resignation), the next sync job detects the disabled status and removes the user from the commerce platform or marks them inactive. Active sessions are terminated if the integration is configured to do so. Without explicit termination logic, sessions may persist until they expire naturally.

How is a trade customer linked to an LDAP user record?

iWeb uses a matching key (usually email or employee ID) to connect an LDAP user to an existing ecommerce customer record. When the match is found, the user gains access to that customer account's orders, invoices and trade-specific permissions. If the matching fails, the user can authenticate but cannot see the linked account.

What happens if the LDAP server is unavailable during login?

The commerce platform cannot validate credentials and login will fail. If a fallback is configured, cached authentication may be allowed with reduced permissions. Otherwise, users cannot log in. The integration should alert operations so that LDAP availability is restored quickly.

How are LDAP bind credentials stored and rotated?

The service account used by the commerce platform to query LDAP is stored in a secrets vault (e.g. AWS Secrets Manager, HashiCorp Vault) and injected into the platform at runtime. The credential is rotated on a schedule (e.g. quarterly) and both LDAP and the platform are updated simultaneously. Rotation failures must be monitored so that authentication does not break.

Can users have different permissions on different storefronts?

Yes. iWeb can configure separate permission mappings for each commerce platform or storefront. An LDAP user's groups determine their permissions on the main storefront, the B2B portal and the mobile app independently. However, the mappings must be kept synchronized across all platforms.

How are LDAP login failures logged and who investigates them?

Failed LDAP bind attempts (wrong password, user not found, disabled user) are logged with timestamps and usernames. Logs are aggregated in a central security or audit system. Operations and IT security teams use these logs to investigate login incidents and detect brute-force attacks.

Can LDAP be used alongside other identity providers (e.g. Azure AD or Okta)?

Yes, but each provider must be configured separately and users must be assigned to one or the other. Some organizations migrate identity to a cloud IdP over time and need both LDAP and the new provider to work in parallel until migration is complete. iWeb can support a phased transition.

What is the difference between LDAP and LDAPS?

LDAP is the protocol over plain TCP; LDAPS wraps it in TLS encryption. LDAPS is more secure and is recommended for production. The commerce platform and LDAP server must both support LDAPS. If the server uses a self-signed certificate, the certificate must be added to the commerce platform's certificate store.

How are cost centres and approval limits synchronized from LDAP?

LDAP can carry custom user attributes (e.g. cost_centre, manager_id) beyond standard groups. iWeb maps these attributes to commerce fields so that cost-centre rules and approval limits flow from the directory. If the ERP owns the approval limits, those are synced separately from the ERP.

What if a user forgets their LDAP password?

Password resets are handled by the LDAP administrator using Active Directory tools, not by the commerce platform. The commerce platform does not store passwords and cannot reset them. Users must contact their IT helpdesk.

How does the integration handle multi-forest or multi-domain LDAP environments?

If the enterprise has multiple LDAP forests (e.g. separate directories for subsidiaries), iWeb configures the integration to query multiple forests in parallel or fall back between them. Users must be in at least one forest. Ambiguous identities (same username in two forests) are resolved using a priority order or user specification.

Next step

Have a LDAP integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →