How to Set Up SSO for Your ERP (SAML, OIDC, Entra ID, Okta)
how to set up SSO for ERP with SAML Entra ID Okta
Also searched as
- ERP single sign-on SAML OIDC setup
- SSO for on-prem ERP Active Directory
- ERP SAML login fails after SSO
- enable MFA for ERP users
Short answer
Treat the ERP as a service provider and your identity platform (Entra ID, Okta, ADFS, Ping) as the identity provider. Exchange metadata, agree one stable claim that matches the ERP username, map roles by group, keep a local break-glass admin, and handle service accounts and thick clients separately because they usually cannot use browser SSO.
Applies to: ERPs with SAML 2.0 or OpenID Connect support, including NetSuite, Dynamics 365, SAP (via IAS or SAML), Infor (via Infor OS/IFS), and on-prem products through a reverse proxy or LDAP bridge. Exact screens vary by product.
SSO rollout sequence
- 1Confirm what your ERP edition supports: SAML 2.0, OIDC, LDAP/Kerberos or only local passwords. Check licensing, since SSO is sometimes a separate component or tier.
- 2Decide the unique identifier. Pick one claim, such as userPrincipalName or employee ID, that is stable and already equals or can be mapped to the ERP username. Email addresses change; avoid them if you can.
- 3Create the enterprise application in the identity provider, upload the ERP's service provider metadata (entity ID and assertion consumer service URL), and set the NameID format the ERP expects.
- 4Configure the ERP side with the identity provider's metadata or certificate, the sign-in URL and the attribute mapping. Test with a pilot group first.
- 5Map groups to ERP roles if the product supports it. Otherwise keep role assignment in the ERP and use SSO for authentication only.
- 6Keep at least one local administrator account with a long password stored in your vault, so a certificate or provider outage does not lock everyone out.
- 7Inventory non-browser access: thick clients, integrations, scheduled jobs and APIs. Give them service accounts, tokens or certificates, not user SSO.
- 8Enforce MFA in the identity provider's conditional access, then turn off local password login for ordinary users once the pilot passes.
SAML versus OIDC and where each fits
SAML 2.0 is the common enterprise choice for ERPs because it has been supported for many years. The user is redirected to the identity provider, authenticates, and returns to the ERP with a signed assertion. OpenID Connect does the same job with JSON tokens and is more common in newer cloud products and APIs.
Whichever you use, the ERP still needs a local user record. SSO proves who the person is; it does not create the ERP's roles, approval limits or company access. Some products support just-in-time provisioning, others require users to be created first, so plan the joiner and leaver process around that.
The failures that waste the most time
Most failed rollouts come from mismatched identifiers. The assertion carries jsmith@corp.com but the ERP user is JSMITH or an employee number, so login ends with 'user not found'. Fix the mapping rather than renaming users, and check case sensitivity and domain suffixes.
The next group is clock and certificate issues. SAML assertions are time-bound, so a skew of a few minutes between servers can reject them. Signing certificates expire, commonly every one to three years, and nobody remembers until Monday morning. Put the expiry date in your calendar and monitoring.
# Quick checks when SAML login fails # 1. Decode the SAMLResponse from the browser network trace (base64) and read NameID and Audience # 2. Compare Audience with the ERP's entity ID exactly # 3. Check NotBefore / NotOnOrAfter against server time (NTP) # 4. Check the signing certificate thumbprint in the ERP matches the IdP
Thick clients, APIs and service accounts
Not everything in an ERP estate uses a browser. Desktop clients, Excel add-ins, EDI jobs and integration platforms often authenticate with a username and password or a token. Decide for each whether it moves to modern auth, to a certificate or OAuth client credentials, or stays on a restricted local account.
Do not exempt these by leaving local passwords open for everyone. Limit service accounts to the least privilege they need, restrict them by source IP where possible, rotate secrets, and log their activity separately so an auditor can tell humans from machines.
Joiners, leavers and break-glass
SSO moves the leaver control point to the identity provider: disable the person there and they can no longer sign in to the ERP. Existing sessions and API tokens may still live until they expire, so check session timeouts and revoke tokens during offboarding.
Keep a tested break-glass path. A local admin account, protected by a vaulted password and monitored for use, lets you recover when metadata is wrong or the provider is down. Test it twice a year.
Common pitfalls
- !Using email as the key and then discovering that name changes or aliases break logins.
- !Turning off local login before building a break-glass account.
- !Letting the SAML signing certificate expire unnoticed.
- !Forgetting integrations and thick clients that cannot follow a browser redirect.
- !Assuming SSO also assigns roles and company access. In most ERPs it does not.
- !Granting service accounts full administrator rights because it was easier to get the job working.
How an ERP-grounded AI assistant handles this
An AI assistant grounded in the ERP can help after rollout by answering which active ERP users have no matching identity-provider account, which service accounts logged in interactively, and which users still hold local password logins. ERPray queries live ERP data read-only, shows the query, and respects ERP roles. It does not configure your identity provider or change authentication settings.
Frequently asked questions
Does SSO replace ERP roles?
No. SSO handles authentication, proving who the user is. Roles, approval limits and company or site access remain ERP settings unless your product supports group-to-role mapping, and even then you still need to design the roles themselves.
Can we add MFA without SSO?
Sometimes, if the ERP has its own MFA or sits behind a gateway or VPN that enforces it. In most cases the simplest route is SSO through an identity provider that already enforces MFA and conditional access, so the policy lives in one place.
Why does SSO work in a browser but not in the desktop client?
Desktop and add-in clients often use their own authentication protocol and do not follow the browser redirect used by SAML. Check whether the vendor offers a modern auth or token option for that client, or keep a controlled alternative for it.
What happens if the identity provider is down?
Users cannot sign in through SSO until it recovers. That is why you keep a vaulted local administrator account and test it. Plan for it in your continuity process rather than discovering the dependency during an outage.
Related
How to Run an ERP User Access Review (Quarterly Checklist)
An ERP user access review is a recurring control where system owners confirm that every active user, role and privileged permission is still justified. Extract users and roles from the ERP itself, join them to HR status, send each business owner a scoped list to certify or revoke, record the decisions, and execute the removals with ticket evidence.
How-toHow to Prepare for an ERP Licensing Audit
Start before the vendor letter arrives: build your own count of named users, concurrent sessions, modules and integrations, map each to the license metric in your contract, and fix the gaps. Most true-up findings come from dormant accounts, users holding roles above what they need, integrations and APIs counted as indirect use, and modules enabled but never bought.
CIO briefingHow to Securely Give an LLM Access to ERP Data
Treat the LLM as an untrusted component. Give it read-only access through a dedicated, least-privilege path that enforces the asking user's ERP permissions, validate and log every query it generates, require human approval for any write, and decide deliberately where the model runs. Security comes from the architecture around the model, not from the prompt.
How-toERP Patching Cadence: How Often Should You Patch?
Patch the ERP stack in layers on different clocks: operating system and database monthly or quarterly, ERP vendor cumulative updates quarterly or semi-annually, and security fixes on an emergency path measured in days. Test every patch in a sandbox refreshed from production, with a scripted regression and a tested rollback.
How-toHow to Test ERP Backup and Disaster Recovery
A backup is only proven when you have restored it and a user has transacted in the restored system. Define RTO and RPO with the business, restore the full ERP stack (database, application, integrations, attachments, secrets) to an isolated environment, run a scripted smoke test, time every step, and record gaps as action items.
How-toHow to Monitor ERP Performance: What to Track and Alert On
Monitor the ERP from the user's side first (response time of a few key transactions), then the layers beneath: database waits, blocking and long queries, application server health, batch and integration job duration, queues and storage. Baseline normal for each, alert on deviation, and keep history so you can answer slow-yesterday questions.
AI for ERPAI for NetSuite, Beyond the Built-In Text Tools
NetSuite's built-in AI covers text generation, not grounded answers on your own data. See how a private LLM over SuiteQL adds real Q&A and controls.
AI for ERPAI for Infor SyteLine and CloudSuite Industrial
Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.
Stuck on ERP identity (vendor-neutral)?
Talk to engineers who work inside ERP identity (vendor-neutral) every week, and who build private AI that answers these questions from your own ERP data.