Which free CRM fits your SSO setup: SuiteCRM SAML and LDAP or EspoCRM OIDC and LDAP
A team that must sign users in through a central identity provider should start with the protocol that provider speaks, because the two free cores cover different protocols. SuiteCRM 8 supports LDAP, enabled with AUTH_TYPE=ldap, and SAML, enabled with AUTH_TYPE=saml. EspoCRM supports OpenID Connect sign-in since version 7.3, and it documents LDAP authentication for both Active Directory and OpenLDAP. If your provider offers SAML 2.0, SuiteCRM is the free core with a built-in SAML option. If it offers OpenID Connect, EspoCRM is the one. Both cores can read directory accounts over LDAP. The final choice depends on three things: which identity provider you run, how logout must behave, and whether the CRM itself must enforce a second factor.
Logout is where the two cores differ most in practice. The SuiteCRM 8.7.0+ SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so ending a session at the identity provider leaves the SuiteCRM session open. EspoCRM's OIDC support includes backchannel logout, which lets the provider end CRM sessions, plus a fallback login method. Two-factor authentication is the other constraint: EspoCRM's own 2FA is not compatible with OIDC, so teams using OIDC must enforce second factors at the identity provider. Confirm with SuiteCRM whether its own 2FA can be enforced alongside SAML or LDAP in the version you plan to run, and test that answer on a staging instance before you commit.
Map the choice to your identity estate. Keycloak is an Apache 2.0 open source identity server that supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it can federate user directories, so it can sit in front of either CRM and act as one sign-in point. For an Active Directory estate, both cores can use LDAP, but group-based access works differently: EspoCRM maps identity provider groups to teams during OIDC sign-in, and you should confirm how SuiteCRM handles group-based roles in your setup. For Microsoft Entra ID, confirm the supported connection, claim mapping and logout path with each vendor before planning the build. Run a proof of concept that signs a test user out at the identity provider and checks whether the CRM session ends.
How SuiteCRM and EspoCRM handle each SSO and directory requirement
This table compares how SuiteCRM 8 and EspoCRM handle each single sign-on and directory requirement in their free cores. Treat cells marked to confirm as open questions for the vendor, not settled answers. The main takeaway: EspoCRM's documentation covers more of the OIDC login lifecycle, while SuiteCRM's documented SAML logout limit is the first item to test against your identity provider.
| Requirement | SuiteCRM 8 | EspoCRM |
|---|---|---|
| Protocol support | SAML (AUTH_TYPE=saml) and LDAP (AUTH_TYPE=ldap) | OpenID Connect since 7.3, and LDAP |
| Directory sign-in | LDAP via Symfony Security; confirm Active Directory settings with SuiteCRM | LDAP documented for Active Directory and OpenLDAP |
| User provisioning on first login | Not documented in supplied sources; confirm before relying on it | Optional user creation on first OIDC login |
| Group or team mapping | Not documented in supplied sources; confirm role mapping from IdP groups | Identity provider groups map to EspoCRM teams |
| Logout behavior | SAML 8.7.0+ has no IdP-initiated logout, so IdP logout leaves the SuiteCRM session open | Logout behavior at the IdP not detailed in supplied sources; test end to end |
| Backchannel logout | Not documented in supplied sources; confirm with SuiteCRM | Supported |
| 2FA compatibility | Not documented in supplied sources; confirm whether IdP-enforced MFA covers sign-in | EspoCRM's own 2FA is not compatible with OIDC; confirm IdP-enforced MFA |
| Documented fallback login | Not documented in supplied sources; confirm with SuiteCRM | Fallback login method supported with OIDC |
Factors that change the SSO result in practice
Both CRMs can sign users in through an external directory, but the identity provider, the logout behavior, the second factor and the team's hosting skills decide which one holds up in production. Check each card against your own environment before you commit to either product.
Identity provider type
The protocol your identity provider speaks sets the shortlist. SuiteCRM 8 offers SAML and LDAP sign-in, while EspoCRM offers OpenID Connect and LDAP, so a Keycloak or Entra ID tenant that is set up for OIDC or SAML needs a check that the matching option is supported in the release you plan to run. For Active Directory, both products can use LDAP, so confirm the bind account, group search and TLS settings with your directory team before testing. Keycloak supports OpenID Connect and SAML 2.0, so it fits either product.
Logout must end the CRM session
If a security policy requires that signing out at the identity provider also ends CRM access, this factor decides the result. The SuiteCRM 8.7.0+ SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so a session can outlive the logout at the identity provider. EspoCRM documents backchannel logout as part of its OIDC support. Test the exact logout path with your provider and a second browser before you accept either behavior.
Where two-factor authentication lives
EspoCRM's own two-factor authentication is not compatible with OIDC sign-in, so the second factor must come from the identity provider when you use that path. Confirm that your provider enforces MFA for every CRM user, including API and service accounts that may not use the browser flow. If you rely on LDAP, check how the second factor is applied in the directory chain, because the CRM will not add it for you.
Group-to-role mapping
Access in the CRM depends on how directory groups become roles or teams. EspoCRM can map identity provider groups to its teams and can create users on first login, which reduces manual admin work but also means the group design must be settled first. SuiteCRM's role model must be mapped in its own configuration, so ask for a worked example that covers your sales, service and admin groups. Review nested groups and group changes for leavers before go-live.
Team skills in PHP and the web server
Both products run on PHP with MySQL or MariaDB, and EspoCRM also supports PostgreSQL 15. SuiteCRM 8.10.x lists Apache 2.4 as supported, while EspoCRM supports Apache, Nginx or IIS and needs cron or a scheduled task for background jobs. Authentication settings live in configuration files and web server directives, so a team comfortable with Apache modules may find SuiteCRM simpler, while a team on Nginx may find EspoCRM's stack easier to run. Confirm the skills you have before you assign the SSO build.
Keeping up with releases
The SSO configuration must survive each upgrade. SuiteCRM 8 minor releases arrive roughly every eight weeks, and patch releases contain only security and bug fixes, which makes SSO changes easier to plan. EspoCRM 10.0 is the current line, so check the release notes for OIDC and LDAP changes before each upgrade. Keycloak plans four minor releases a year, so the identity side will also change, and you should test both sides together.
How Keycloak and Entra ID fit each CRM's login flow
Keycloak can sit in front of either CRM, but the protocol you choose decides what the CRM can actually do. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it can broker sign-in to an upstream identity provider, so a single Keycloak realm can front a CRM while Keycloak itself federates users from Entra ID or Active Directory. On the CRM side, SuiteCRM 8 offers SAML through the AUTH_TYPE=saml setting and LDAP through AUTH_TYPE=ldap, while EspoCRM offers OpenID Connect (since version 7.3) and LDAP. Map each CRM to one protocol in the design document before anyone configures a client, because a Keycloak OIDC client and a SAML client are not interchangeable.
Entra ID and Active Directory connections depend on which protocol and directory path each CRM supports, and these details change between releases. Check whether your Entra ID tenant will reach each CRM through OIDC, SAML or a directory bind, and whether group membership can drive role or team assignment on your chosen CRM version. Confirm the exact settings against the SuiteCRM 8 LDAP configuration and EspoCRM OIDC docs before you commit to a design, and test with a non-production realm.
Keycloak's operational footprint matters as much as its protocol support. It supports production databases including PostgreSQL (14 to 18), MariaDB and MySQL, and its high availability designs require a synchronously replicated database, so the identity layer adds a database and clustering commitment to your CRM estate. Plan who operates Keycloak, how its upgrades are approved and who owns the realm configuration, since an identity outage stops every CRM behind it.
How to test SSO behavior in your own environment
This sequence gives you a side-by-side record of how SuiteCRM and EspoCRM handle sign-in, user creation, group mapping, logout and 2FA against your own identity provider, so the choice rests on observed behavior rather than feature lists.
Fix the identity provider and protocol
Before building anything, the identity or security team records which identity provider you will test against (for example, Keycloak, Entra ID or Active Directory) and which protocol each CRM will use. SuiteCRM 8 supports LDAP through AUTH_TYPE=ldap and SAML through AUTH_TYPE=saml, while EspoCRM supports OpenID Connect since version 7.3 and LDAP, including Active Directory and OpenLDAP. Write down the attributes, group claims and logout endpoints you expect each CRM to receive. The step is done when the team has one signed-off test matrix listing the protocol, the identity source and the expected result for each CRM.
Build a staging instance of each CRM
The platform or implementation team installs SuiteCRM 8 and EspoCRM in separate staging environments that mirror production hosting, database and certificate setup as closely as possible. Use the current supported versions listed in each vendor's compatibility or server configuration documentation, and confirm the PHP, database and web server combinations before installation. Keep the two environments isolated from production user data. The step is done when both instances load over HTTPS, an administrator can log in with a local account, and the versions are recorded in the test log.
Test first sign-in and user creation
The identity team creates a test user in the directory or identity provider and signs in to each CRM for the first time. Confirm whether the CRM creates the user record automatically on first login, which fields arrive (name, email, username) and whether a user with no matching record is refused. For EspoCRM, check whether automatic user creation is enabled in the OIDC settings. The step is done when each CRM has a screenshot or log entry showing the created or rejected account, with the attribute mapping noted.
Test group mapping and role assignment
Assign the test user to two identity provider groups with different intended access levels. Sign in to each CRM and check how groups are reflected: in EspoCRM, confirm whether identity provider groups map to teams as expected. For SuiteCRM, confirm which roles or access rules apply to the account, since group handling depends on the chosen LDAP or SAML configuration. Move the user out of a group, sign in again and confirm access changes. The step is done when a table shows each group, the resulting CRM team or role and the access test that proves it.
Test logout from the CRM
Sign in to each CRM through the identity provider, then log out from inside the CRM. Confirm whether the CRM session ends and whether the identity provider session remains active, then open the CRM in a new browser session to check whether a silent sign-in occurs. For EspoCRM, test whether backchannel logout ends the session after the identity provider sends a logout event. The step is done when the team records the observed behavior for each CRM, including any session that survived logout.
Test logout from the identity provider
Sign in to each CRM, then end the session at the identity provider, either through its portal or by revoking the session in the admin console. Return to each CRM and attempt a protected action. Note whether the CRM session continues. The SuiteCRM 8.7.0+ SAML implementation does not support IdP-initiated logout, so expect the SuiteCRM session to remain active unless you have confirmed a different configuration. The step is done when the team has a documented result for each CRM and a list of compensating controls, such as shorter session lifetimes, that the security team wants to review.
Test 2FA enforcement
Confirm what second factor applies to each sign-in path. EspoCRM's own two-factor authentication is not compatible with OIDC, so the team should verify that the identity provider enforces MFA for the test user. For SuiteCRM, confirm whether the chosen LDAP or SAML path relies on the identity provider's MFA policy. Attempt sign-in without the second factor and record whether access is blocked. The step is done when the team can show that MFA is enforced at the identity provider for each sign-in path, or that a gap exists and needs a documented decision.
Test directory lockout and password change
Disable the test account in the directory, then attempt to sign in to each CRM. Reset the password, then check whether the old password is rejected and whether the CRM accepts the new one. Repeat with a locked account to confirm that lockout propagates. Record whether an existing CRM session survives the disable action. The step is done when each CRM's response to disabled, locked and changed accounts is recorded, and any session that persists after disablement is flagged for a remediation decision.
Record results and confirm open items
The project lead compiles the test matrix into one document showing each scenario, the observed result for SuiteCRM and EspoCRM and the evidence. Mark each gap with an owner, such as the platform team for session settings or the identity team for MFA policy. Ask each vendor or your implementation partner to confirm any behavior that tests could not establish. The step is done when the security lead signs off the record and it is stored with the design decision, so the outcome can be reviewed at the next upgrade.
Common questions about SuiteCRM and EspoCRM SSO
Do both free CRM cores support single sign-on without a paid plan?
Yes, both free cores include a login method that federates identity: SuiteCRM 8 supports LDAP and SAML through AUTH_TYPE settings, and EspoCRM supports OpenID Connect since version 7.3 and LDAP, including Active Directory and OpenLDAP. The paid parts sit elsewhere. EspoCRM's paid Advanced and Sales Packs add reports, workflows and sales modules, not sign-in. Confirm the exact configuration keys and any feature limits against the current SuiteCRM and EspoCRM documentation for the version you plan to run, since login options change between releases.
What does the internal team need to supply for SSO setup?
The work needs three things from your side: an administrator for the identity provider who can register the CRM as a client or service provider, a directory owner who can confirm which groups or attributes map to CRM roles, and someone who runs the CRM host and can manage TLS certificates and the login configuration files. Expect to test with a staging instance first. The mapping of groups to teams or roles is where most of the design decisions sit, so it should be written down before configuration begins.
Can a team configure SSO alone without outside help?
A team with a working SuiteCRM or EspoCRM install, administrative access to Keycloak, Entra ID or Active Directory, and experience with certificates and SAML or OIDC metadata can often complete a basic login flow alone. Risk rises when the work includes role mapping, account provisioning on first login, logout behavior or a plan to close the logout and 2FA gaps. A written review of those points, whether internal or from an implementation partner, reduces the chance of a login that works in testing but fails in production.
How long does SSO setup take for each CRM?
Duration depends on the environment, not on the product alone: how many identity providers are involved, whether group mapping is needed, how many users exist, whether an existing directory is clean, and how many test cycles your change process requires. No public duration figure applies to your case, so ask any implementer for a timeline built from a written scope and a list of the systems that must be reached. Ask which items are fixed in that scope and which depend on your directory data.
What should a written quote for SSO work include?
A useful quote lists the CRM version and login method, the identity provider and its version, the directory or groups to be mapped, whether first-login account creation and team mapping are included, how logout and 2FA are handled, the staging and production test plan, documentation handover, and any post-go-live support. It should also state what the client provides, such as admin access and certificates. Costs are one-time for design and configuration and may recur if support or upgrade retainers are added. Ask for each item to be priced separately so you can see what drives the total.
Can logout and 2FA gaps be closed on each side?
Partly, and the answer differs by CRM. SuiteCRM's SAML implementation in 8.7.0 and later does not support IdP-initiated logout or POST binding to the logout service, so ending a session at the identity provider does not end the SuiteCRM session; mitigations include short session lifetimes and a documented user habit, and you should confirm what the current release supports. EspoCRM's own 2FA is not compatible with OIDC, so second factor must come from the identity provider. OIDC backchannel logout is available in EspoCRM. Test each path before you rely on it for regulated access.
Which option fits Keycloak, Entra ID or Active Directory?
Both CRMs can be pointed at a directory or identity provider, but the fit depends on the protocol you run. Keycloak speaks OpenID Connect and SAML 2.0, so either CRM can use it, and EspoCRM's OIDC support and SuiteCRM's SAML support both apply. For Entra ID, the choice usually follows the protocol your tenant and application registration support. For direct Active Directory binding, both support LDAP, and EspoCRM documents Active Directory explicitly. Confirm the exact attribute and group mapping with your directory owner before choosing.
When single sign-on should decide the shortlist
Single sign-on should decide the shortlist when the organization mandates central identity, logout propagation or enforced multi-factor authentication at the identity provider. If policy says every CRM session must follow the directory account, including disablement on leaver events, the CRM has to accept that control rather than run its own login. In this comparison, that test separates the two platforms quickly. SuiteCRM 8 can authenticate against LDAP through AUTH_TYPE=ldap or against SAML through AUTH_TYPE=saml, but its 8.7.0+ SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so ending a session at the identity provider does not end the SuiteCRM session. EspoCRM supports OpenID Connect with backchannel logout, group-to-team mapping and a fallback login method, but its own two-factor authentication is not compatible with OIDC. Each gap needs a named compensating control before go-live.
Where these needs are light, the decision usually moves elsewhere. If the CRM is a contained sales team's tool, reached through a single network segment and governed by a short user list, LDAP or a local account may satisfy policy, and the choice should turn on the team's PHP skills, the modules they need and whether they will buy paid extensions. EspoCRM's Advanced Pack and Sales Pack, and SuiteCRM's module depth, can shape the total effort more than the login method does. Confirm with your identity team which of the controls above are actually mandated, in writing, before weighing SSO above those factors.
Before deciding, run three checks against your own identity provider. Confirm which protocol your Keycloak, Entra ID or Active Directory deployment will issue for the CRM, and whether the directory group model maps cleanly onto the CRM's roles or teams. Test a leaver scenario end to end and record whether the CRM session ends when the directory account is disabled. Finally, ask the vendor or your integrator to demonstrate how each product behaves with your MFA policy, since the answer depends on your identity provider configuration and not on the feature list alone.
How DeployOpen helps evaluate and implement SSO for your CRM
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For SuiteCRM and EspoCRM, that means testing the sign-in paths your identity provider actually uses, then recording what each path does and does not cover, including logout and two-factor behavior.
How we scope
- Confirm which identity source you run, such as Keycloak, Entra ID or Active Directory, and who must sign in.
- Agree in writing which sign-in method, user provisioning and group mapping are in scope before work starts.
- Record logout, session and two-factor expectations so gaps are known before any build begins.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- Configure the chosen login method in a staging instance with your identity provider or directory test accounts.
- Map directory groups to CRM roles or teams and test that access matches your existing permission model.
- Test failure paths, including disabled accounts, expired passwords and a fallback login for administrators.
- Check the behavior of identity provider logout against each CRM session before anything reaches production.
How we hand over
- Document the configuration keys, certificate handling and directory settings used in your environment.
- Write a runbook covering login, logout, account lockout and two-factor limits for your support team.
- Walk your administrators through the setup and the known gaps, with the decisions recorded in writing.
- Provide an upgrade checklist that re-tests sign-in after each SuiteCRM or EspoCRM release you apply.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retesting of sign-in after identity provider changes, certificate renewals or CRM upgrades can be scoped separately.
- Confirm with your auditor or assessor which sign-in evidence they expect, since DeployOpen prepares evidence but does not attest to it.
- Ask for a written scope and quote that lists which identity provider versions and CRM versions are covered.
