How SuiteCRM SAML single sign-on with Entra ID works
SuiteCRM 8 supports SAML login, enabled with AUTH_TYPE=saml, and Microsoft Entra ID can act as the identity provider for it. If your team wants staff to sign in to SuiteCRM with their Entra ID accounts, this is the mechanism that moves the password check out of SuiteCRM and into your directory. The identity provider is the system that verifies who a person is and vouches for them. SuiteCRM is the service provider: it trusts that vouching and decides what the signed-in user can do inside the CRM. Entra ID does not replace SuiteCRM's own user records, so the two systems must agree on who each person is.
In a typical sign-on, a user opens the SuiteCRM login page and is redirected to Entra ID. After the user authenticates there, Entra ID sends a signed SAML response back to SuiteCRM through the browser. SuiteCRM checks the signature and the assertion's validity conditions, reads the user identifier in the assertion, and looks for a matching SuiteCRM account. Confirm in the 8.7.0+ SAML configuration reference how SuiteCRM behaves when no account matches, and whether it can create an account on first sign-on in your release. The answer determines how much of your onboarding work stays with the CRM administrators.
Users must still exist as SuiteCRM accounts. Entra ID proves identity, but it does not assign SuiteCRM roles, teams or permissions for you. Plan the account lifecycle before go-live: who creates accounts, who assigns roles, how accounts are deactivated when someone leaves, and which Entra ID attribute is used to match the SuiteCRM username. The SuiteCRM 7.x Azure guide matches usernames to Azure email addresses. That is a reasonable starting assumption, but check it against your directory data and the 8.x settings before you rely on it.
The SuiteCRM admin guide's Azure SAML page is written for SuiteCRM 7.x. Its screens and some settings differ from SuiteCRM 8, so take every SuiteCRM 8 setting from the 8.7.0+ SAML configuration reference and use the 7.x guide only as background. Also confirm the exact SuiteCRM 8 release you are running. The 8.x upgrade documentation says an existing SAML configuration must be updated before upgrading to 8.7.0, so an older SAML setup needs review as part of any version change.
What you need before you register the Entra ID application
Six items settle whether the Entra ID application can be registered and tested without rework. Together they cover the SuiteCRM version, the platform beneath it, the addresses each environment answers on, the Entra ID access needed, the people who will sign in, and the trust material exchanged between the two systems.
SuiteCRM 8.7.0 or later
SAML sign-on in SuiteCRM 8 is enabled with AUTH_TYPE=saml, and the SAML behavior described in this guide applies from 8.7.0 onward. Confirm the version running in each environment before you start. If an existing SAML configuration is already in place, the SuiteCRM upgrade documentation says it must be updated before upgrading to 8.7.0, so schedule that change into the upgrade window.
Supported PHP, web server and database
Check the SuiteCRM compatibility matrix for the exact release you run, because supported versions change between minor releases. The matrix for SuiteCRM 8.10 lists PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4, on Linux, Unix or macOS. Confirm which of these your target version supports, and record the chosen versions for each environment.
Public HTTPS URL per environment
Each SuiteCRM environment needs its own public HTTPS address that the user's browser can reach and that the identity provider can redirect to. In the Azure SAML setup, the Entity ID, Reply URL and Sign-on URL all use the CRM address followed by the index.php path with action Login and module Users. Agree these addresses with your network team before registering anything, because a hostname change later means updating the Entity ID and Reply URL together.
Entra ID role for enterprise applications
You need an account in your Microsoft Entra ID tenant that can register enterprise applications and configure single sign-on for them. Confirm with your tenant administrator which role your tenant policy grants for this, since access is often restricted. SuiteCRM notes that SAML applications are unique to each instance, so staging, test and production each need their own registration, and the account must be able to create all of them.
Matched users in both systems
Every person who signs in must exist in Entra ID and in SuiteCRM, with the SuiteCRM username equal to the user's Entra ID email address. Build the list from your identity records, then check each address for spelling and letter-case differences, because a mismatch blocks sign-in for that person. SAML2Authenticate is enabled per user, so add that setting to the list when you plan the rollout.
Metadata and signing certificate exchange
The identity provider metadata and its signing certificate must move between Entra ID and SuiteCRM before a sign-in test can pass. Decide who downloads the metadata, who installs it in each environment's configuration, and who receives the alert when the certificate nears expiry. Keep the values for each environment separate, since each registration produces its own metadata and certificate.
Configuring SuiteCRM SAML single sign-on in the Entra ID app
This sequence creates a dedicated Entra ID enterprise application for each SuiteCRM environment, connects its SAML endpoints and username claim to the CRM, and ends with tested sign-in behavior in staging. Each step closes with a check so the team confirms it before moving on.
Create a dedicated enterprise application
An administrator in the Microsoft Entra admin center creates a new custom SAML enterprise application for this SuiteCRM environment. Do not reuse an application from another instance, because SuiteCRM notes that SAML apps in Azure are unique to each instance, so staging, test and production each need their own. The step is complete when the staging application exists under its own name and has its own single sign-on settings page.
Set the Entity ID and sign-on URLs
In the application's basic SAML configuration, set the Entity ID, Reply URL and Sign-on URL to the CRM base address followed by index.php?action=Login&module=Users, as the SuiteCRM Azure SAML guide describes. Use the exact host name and scheme that users will type, and keep all three values identical. Check: a text comparison of the saved values against the CRM address shows no differences.
Map the username claim to email
Configure the SAML attributes and claims so the username value sent to SuiteCRM is the user's email address. The SuiteCRM Azure guide requires SuiteCRM usernames to match Azure email addresses, so this mapping decides whether sign-in succeeds. Confirm the exact claim and attribute names in the SuiteCRM 8.7.0+ SAML configuration reference before saving. Check: the claims preview for a test user shows the email value in the field SuiteCRM will read.
Download and verify the federation metadata
Download the federation metadata from the application's SAML settings, using the current export option in the Entra admin center. Confirm that the entity ID, signing certificate and single sign-on endpoint in the file match the values the SuiteCRM settings will reference. Note the certificate expiry date so the team can plan renewal before it lapses. Check: the metadata file loads in a parser without errors and lists the expected entity ID.
Set SuiteCRM SAML settings and AUTH_TYPE
In the staging SuiteCRM 8 instance, enter the identity provider details from the metadata and set AUTH_TYPE to saml, following the 8.7.0+ SAML configuration reference. Confirm every setting name, file location and certificate format in that reference, because this outline does not list them. If an existing SAML configuration is present, update it before upgrading to 8.7.0. Check: after the application restarts or the cache is cleared as the reference directs, the login page shows the SAML path.
Assign staging test users
Assign a small group of staging test users to the enterprise application in Entra ID. Confirm that each one has a SuiteCRM account whose username equals the email address in Entra ID, because the 7.x guide requires users to exist in both systems. Check the 8.7.0+ reference for whether sign-in creates accounts before relying on that behavior. Check: each assigned user appears in the application's Users and groups list with the expected account.
Test sign-in and refusal in staging
Sign in as an assigned test user and confirm the CRM session opens with the expected profile. Next, attempt sign-in with a user who has no SuiteCRM account and with a user not assigned to the application, and confirm both are refused. Record that signing out at Entra ID does not end the SuiteCRM session, because 8.7.0+ does not support IdP-initiated logout. Check: the test log records each outcome and the team has agreed how users will sign out of the CRM.
Matching Entra ID users to SuiteCRM accounts
This table compares the identity and account settings that decide whether an Entra ID sign-in lands on the right SuiteCRM user. Read each row as a check to complete before pilot users sign in. The main takeaway is that the identifier sent by Entra ID must match the SuiteCRM username exactly, and that SuiteCRM account existence, roles and disabled status must be confirmed in SuiteCRM itself.
| Field | Setting or behavior | Where it usually fails |
|---|---|---|
| Identity attribute | Email address, as the SuiteCRM 7.x Azure guide specifies. Confirm the 8.x attribute mapping before using UPN. | UPN differs from the mail value after a domain change or alias |
| Username match | Each SuiteCRM username must equal the identity value Entra ID sends, including case handling. | Legacy usernames carried over from older instances |
| Missing SuiteCRM account | The 7.x guide requires the user to exist in SuiteCRM. Confirm what 8.x does on first sign-in with no match. | Users assigned in Entra ID but never created in SuiteCRM |
| Enterprise application assignment | Assigned users or groups can start sign-in. Assignment does not create or change a SuiteCRM account. | Teams assume assignment provisions the CRM user |
| SuiteCRM roles | Confirm in the SAML reference whether roles come from attributes. Plan to set them in SuiteCRM unless confirmed. | Group claims expected to grant roles that SuiteCRM never reads |
| Disabled SuiteCRM accounts | Confirm that a deactivated user is refused at SAML login. Test with a disabled account before go-live. | Disabled users keep access through an existing session |
| Disabled Entra ID users | Disabling the user in Entra ID stops new sign-ins. It does not end an active SuiteCRM session. | Logout at the identity provider is assumed to end the CRM session |
| Per-user SAML flag | The 7.x guide enables SAML2Authenticate per user. Confirm the equivalent control in 8.x. | Some users left on password login during rollout |
Per-environment apps and certificate handling
Each SuiteCRM environment needs its own Entra ID enterprise application. The SuiteCRM admin guide for Azure SAML notes that SAML apps are unique to each instance, so staging, test and production each need their own application, Entity ID and signing certificate. Sharing one application across environments means that a certificate rotation, a hostname change or a configuration error in one environment can break sign-in in the others. Before you create the first app, agree a naming convention that includes the environment and the SuiteCRM hostname, and record which app belongs to which SuiteCRM instance. Staging should be the first place a new app and certificate are tested, so that production sign-in is never the first live test.
In each environment's enterprise application, Entra ID provides a SAML signing certificate and federation metadata that you download for that app. Take both from the same application so that they match, and do not copy a certificate from one environment's app into another. Record the certificate's thumbprint, expiry date, the application's name and object ID, the environment it serves and the date you installed it. SuiteCRM needs the identity provider's public certificate to verify signed assertions, and the private signing key stays with Entra ID. Install the certificate only into the SuiteCRM instance it belongs to. Before you do, confirm against the 8.7.0+ SAML configuration reference the certificate format SuiteCRM expects, whether a separate service provider key pair is needed, and the exact names of the certificate settings in your version.
Signing certificates expire, and when one does, sign-in fails for every user of that environment at once. Confirm in your own Entra ID tenant how new certificates are created ahead of expiry, whether a new certificate must be activated manually, and how long the old and new certificates overlap. Then plan the change as a fixed sequence: install the new certificate in staging, test with a named test user, repeat in test, and only then change production during an agreed window. Keep the previous certificate available until the new one is confirmed. Maintain a renewal register with one row per environment that lists the app name, expiry date, owner, installation date and where the metadata file is kept, and set reminders well before each expiry date.
The renewal register also needs to cover upgrades. The SuiteCRM 8 upgrade documentation says that an existing SAML configuration must be updated before upgrading to 8.7.0, so certificate and setting changes may coincide with a platform upgrade. Schedule certificate renewal and SuiteCRM upgrades separately where you can, and re-test sign-in in each environment after either change. If you ask DeployOpen or another partner to build this, the written scope should name each environment's app and certificate, the installation steps for each environment, the test cases used to confirm sign-in, and the rotation runbook your admins will follow after handover. Ask for the same items in any internal estimate so that the cost of repeating the work for every environment is visible.
Hardening SAML sign-on for SuiteCRM
These six controls sit around the SAML setup. They decide who can sign in, how the trust relationship stays protected and how the team regains access if sign-on fails. Most of them are the team's responsibility, so review the Entra ID conditional access policies you choose with your identity team, because SuiteCRM does not enforce those sign-in conditions.
Restrict the enterprise application
Turn on user assignment required for the SuiteCRM enterprise application in Entra ID, then assign only the people who need CRM access. Without this setting, any account in the tenant that reaches the application can attempt sign-on. SuiteCRM still needs a matching user record for each person, so compare the assignment list with the users that exist in SuiteCRM. Review removals as part of joiner and leaver steps, because the assignment list is the effective access list for this application.
Require HTTPS on every URL
Every SuiteCRM URL that the SAML flow touches must use HTTPS, including the Entity ID, the reply URL, the sign-on URL and the login page. The Azure setup builds all three identifiers from the CRM URL plus the login route, so one plain HTTP address in the configuration can break trust or expose sign-on traffic. Check the base URL in the SuiteCRM configuration, the URLs in the Entra ID application and any proxy or load balancer that rewrites the scheme. Test the redirect path from outside your network.
Keep SuiteCRM and PHP patched
Stay on a supported SuiteCRM 8 minor release and apply patch releases as they are published. Patch releases contain only security and bug fixes, with no new features or database changes, which makes them the lowest-risk way to close known vulnerabilities. Minor releases arrive roughly every eight weeks and need a planned upgrade. Confirm that your PHP version appears in the compatibility matrix for your SuiteCRM release, for example PHP 8.2, 8.3 or 8.4 for SuiteCRM 8.10, and retire hosts that run unsupported versions.
Limit who changes SAML settings
The SAML settings in the admin panel decide which identity provider is trusted and where sign-on is sent, so changing them can change who gets into the CRM. Limit the administrator role to a small, named group and keep an audit trail of configuration changes. Place SAML changes under the same change control as other production configuration, and agree in advance who approves a certificate rollover or a new environment. Confirm in the SuiteCRM admin guide which role can open this panel in your version.
Protect the private key and certificate
The service provider private key and the Entra ID signing certificate anchor the trust in this integration. Store the private key outside publicly served paths, with file permissions that only the web service account and the deployment process can read, and keep it out of shared repositories and tickets. Record the certificate expiry date and plan the rotation with the identity team before it lapses. Back up the key under the same access controls as the database backup, and confirm where each copy is held.
Keep a tested local administrator path
If the identity provider, a certificate or a conditional access policy blocks sign-on, someone must still reach the admin panel. Decide the recovery path before go-live, either a local administrator account with a credential stored separately or a documented break-glass procedure. Confirm whether local login remains available when AUTH_TYPE is set to saml. Test the path on staging, record the steps and an owner, and check it again after each SAML change.
Where SuiteCRM SAML single sign-on stops at logout
In SuiteCRM 8.7.0 and later, the SAML implementation does not support IdP-initiated logout or POST binding to the logout service. When a user signs out of Microsoft Entra ID, the identity provider session ends, but the SuiteCRM session in the browser remains valid until it expires or the user signs out of SuiteCRM itself. Signing out at the identity provider and signing out of SuiteCRM are two separate events, and the first does not trigger the second.
What this means in practice:
- Signing out of the Microsoft portal, My Apps or another Entra-protected application does not end the SuiteCRM session.
- A user who opens SuiteCRM again in the same browser may reach the application without a new sign-in prompt, depending on the session that remains.
- Disabling a user in Entra ID stops new sign-ins, but test whether it also ends an existing SuiteCRM session in your version.
- SuiteCRM's own sign-out is the supported exit path, so confirm that it clears the session as you expect.
Confirm this behavior on the exact SuiteCRM version you deploy before describing it to a security team.
The gap has the most practical consequence on shared devices. Shared workstations, service desk seats, kiosks and hot-desking setups can leave an open CRM session for the next person to use. That person may reach the previous user's customer records and act under that account until the session ends.
The situations to list in your environment include:
- Front-desk or service desk computers where staff change shifts without signing out of every application.
- Users who close the browser window but leave the browser process running, or who rely on session restore features.
- Roles with access to customer personal data, financial details or sensitive case notes, where a misused session carries more risk.
- Personal devices used for work with a shared household profile, which are less common but still possible.
- Browsers set to remember sign-in state on machines that other people can open.
A written rule helps: users sign out of SuiteCRM and close the browser before leaving any shared device. List which seats are shared before deciding how much weight that rule needs.
The length of time a SuiteCRM session stays valid, both after sign-in and after inactivity, determines how long the gap matters. Plan around the settings in your SuiteCRM 8 configuration and in any reverse proxy or load balancer in front of it. Do not assume that Entra ID session settings govern the SuiteCRM session once it is established, because the SuiteCRM session is held by the application.
When you plan the lifetime, work through these points:
- Identify every timeout that applies, including the SuiteCRM session settings and any proxy or load balancer timeouts.
- Separate idle timeout from absolute session lifetime, since they affect shared machines in different ways.
- Check which Entra ID conditional access controls apply at sign-in, and confirm whether they affect a session that is already active.
- Test with a session on a staging instance and record the observed behavior for each timeout.
- Enter the chosen values in the risk register so reviewers can see the trade-off with user productivity.
Write down the timeout values you intend to use, the reason for each, and who approved them before go-live.
No single control removes the logout gap in this SAML implementation, so most teams combine several measures. Each option has a cost in user friction, support load or change control. Choose the combination according to the sensitivity of the data users reach and the sharing patterns on your devices.
The options to consider are:
- Shorter session timeouts: reduce the window in which an open session can be reused, at the cost of more frequent sign-ins.
- User guidance: short instructions on signing out of SuiteCRM and closing the browser, included in onboarding and repeated at role changes.
- A documented sign-out step: a written procedure for shift changes and shared seats, with a named owner who reviews it.
- Device controls: screen-lock timeouts and browser settings managed through your endpoint tooling.
- Compensating reviews: periodic checks of access records where your tooling supports them. Confirm what SuiteCRM logs before relying on this control.
Ask your security team which combination meets your policy for shared access before you publish the procedure.
Logout behavior depends on the SuiteCRM version, the SAML library it uses and the Entra ID configuration. A statement that holds for one release may not hold for another, so test the exact combination you will run. Do this before you describe logout behavior to a security team, an auditor or a customer.
The testing steps are:
- Confirm your SuiteCRM version and read the SAML configuration reference that matches it.
- Confirm whether your version supports IdP-initiated logout and POST binding to the logout service, and record the answer.
- Sign in through Entra ID, sign out at the identity provider, then open SuiteCRM in the same browser and record the result.
- Sign out of SuiteCRM, then check the identity provider session and record that result separately.
- Repeat the tests after every SuiteCRM minor upgrade, and review the SAML configuration before upgrading to 8.7.0 or later, as the upgrade documentation requires.
Keep the test record with your change documentation so that any logout statement can be traced to a tested version.
Common SAML failures and how to fix them
This table lists the seven failures teams most often hit when connecting SuiteCRM to Microsoft Entra ID over SAML, with the likely cause, the check to run and the fix for each. Work through the checks in order when sign-in fails, starting with the URLs and usernames. Confirm exact setting names in the SuiteCRM 8.7.0+ SAML configuration reference before you change anything.
| Failure | Likely cause | Check to run | Fix |
|---|---|---|---|
| Entity ID or Reply URL does not match the URL users open | The Entra application uses a different host name, protocol or login path from the SuiteCRM instance. | Compare the Entity ID and Reply URL with the SuiteCRM base URL and login path, character by character. | Correct the Entra values or the SuiteCRM settings so both match, then retest in a private browser session. |
| Username does not match the SuiteCRM account | The SuiteCRM user name differs from the Entra user's email address, which the Azure SAML guide expects to match. | Compare the SuiteCRM username with the Entra user's email, including case and domain. | Rename the SuiteCRM user or correct the attribute mapping so they match, then confirm sign-in. |
| User not assigned to the enterprise application | Entra has no assignment for the user or a group they belong to, so sign-in stops before SuiteCRM is reached. | Check Users and groups on the enterprise application for the affected user or their group. | Assign the user or group to the application, then retry sign-in as that user. |
| Expired or mismatched signing certificate | The certificate SuiteCRM trusts is older than the active signing certificate in Entra, or was replaced. | Compare the expiry date and thumbprint of the Entra certificate with the certificate SuiteCRM holds. | Update the SuiteCRM identity provider settings with the active certificate, then set a reminder before expiry. |
| Staging application used against production | Each SAML application in Entra is unique to one instance, so settings were copied between environments. | Confirm the Entity ID, Reply URL and certificate belong to the target instance and its own Entra application. | Create a separate Entra application for each environment and keep each set of settings with its instance. |
| AUTH_TYPE is not set to saml | SuiteCRM 8 selects its login method with AUTH_TYPE, so SAML settings are ignored when another value is set. | Check the AUTH_TYPE value in the instance configuration and confirm the SAML settings are loaded. | Set AUTH_TYPE to saml as the reference describes, follow any restart or cache step it lists, and retest. |
| Existing SAML configuration left unchanged before upgrading to 8.7.0 | Settings written for an earlier SAML setup may not match the 8.7.0 SAML implementation, so sign-in can fail after the upgrade. | Compare the current settings with the 8.7.0+ SAML configuration reference on a staging instance before upgrading. | Update the configuration to match the reference, test sign-in on staging, then upgrade production. |
Testing SAML sign-on in staging before production cutover
Run the full SAML test plan against a staging SuiteCRM instance with its own Entra ID enterprise application before any change reaches production. SuiteCRM's Azure SAML guidance treats SAML apps as unique to each instance, so staging, test and production each need a separate application. Each one needs its own Entity ID, Reply URL and Sign-on URL, all built from that instance's CRM URL followed by index.php?action=Login&module=Users. Confirm that the staging run points only at the staging URL and leaves the production application unchanged. Also confirm that SAML2Authenticate is enabled for every test user, because the guide enables it per user.
The plan should cover four sign-in cases. First, a successful sign-in for each role your team uses, such as sales, service, marketing and any administrator or read-only group. Each test user must exist in both Entra ID and SuiteCRM. Second, a refused sign-in for a user in the same tenant who is not assigned to the enterprise application, and check that no SuiteCRM account is created or activated as a side effect. Third, a sign-in where the Entra ID username differs from the SuiteCRM account. The Azure guide expects SuiteCRM usernames to match Azure email addresses, so record exactly what happens and decide whether the fix belongs in the account or in the attribute mapping before cutover.
Rehearse a certificate renewal in staging. Generate or import the replacement signing certificate in the staging application, update the SuiteCRM SAML configuration, and confirm that sign-in still works. Then rehearse the rollback. The supplied facts do not give a renewal lead time or expiry period, so confirm the steps and timing with your Entra ID administrator and the SuiteCRM SAML configuration reference for your version. Include a fallback login test as well: confirm which account can still sign in with local credentials if the identity provider is unavailable, test that path, and name the people who hold it. Also verify that signing out at Entra ID does not end the SuiteCRM session, and tell users to log out of SuiteCRM directly.
Back up the files and database before any change, following the SuiteCRM migration guidance, and test the restore on staging as well. Apply the change to staging first and review your customizations, because the migration may remove non-core files under the public/legacy folder. If the change includes a SuiteCRM upgrade to 8.7.0 or later, the upgrade docs require the existing SAML configuration to be updated first, so test that updated configuration. Record every case with the date, tester, environment, SuiteCRM version, Entra ID application name, outcome and evidence such as screenshots or log extracts. Give the change board this record so it can approve or reject the production cutover on the evidence.
Questions buyers ask before hiring help with SuiteCRM SAML
How much does help with SuiteCRM SAML sign-on cost?
The cost depends on the written scope, not on a standard package, and DeployOpen does not publish a price list. A quote follows from the agreed scope, which should separate the Entra ID work (enterprise application, claims, group or role settings, test users) from the SuiteCRM work (AUTH_TYPE=saml configuration, user matching, logout behavior, testing and handover). Each environment you add (staging, test, production) adds configuration and testing. Ask the provider to price each part, state which parts are one-time and which recur, and list what you must supply, such as tenant admin access and certificate handling. A quote that cannot be traced back to these parts is hard to compare with an internal estimate.
How long does a SuiteCRM Entra ID SAML setup take?
No fixed duration applies, because the time depends on how many instances you run, whether a SAML configuration already exists, how many roles need mapping and how quickly your identity team can approve changes. Ask the provider for a schedule that follows the scope, with a staging instance tested before production and a named owner for each approval step. Also ask how the schedule accounts for certificate issuance, since certificate handling often waits on people outside the project team. A schedule that does not name these dependencies usually slips when they arrive.
Can our own team set up SuiteCRM SAML without outside help?
Yes, a capable internal team can set up SAML sign-on, provided it has an Entra ID administrator, a SuiteCRM administrator with Linux and web server access, and a staging instance to test against. The SuiteCRM 8 SAML configuration reference covers the settings, and the SuiteCRM 7 Azure guide shows the Entra ID steps that most teams follow. The harder parts are usually the ones that are easy to miss: keeping user accounts matched to identity provider accounts, deciding what happens at logout, and documenting how the certificate is renewed. Count these in your own estimate, and assign an owner to each before the work starts.
What does the client need to provide before SAML work starts?
Before work starts, you need to provide several inputs and access rights. These include an Entra ID administrator who can create enterprise applications, a list of SuiteCRM instances and their final URLs, and a staging instance that mirrors production closely enough to test login. You also need a decision on how users match: SuiteCRM user names must line up with the identity provider's identifiers, and the SuiteCRM 7 guide requires Azure email addresses to match SuiteCRM user names. Finally, name the people who approve role mapping, certificate ownership and go-live. Missing inputs are a common cause of delays, so confirm them in the written scope.
What makes SuiteCRM SAML effort larger or smaller?
The main drivers are the number of environments, the state of any existing SAML configuration, the role mapping, the certificate process and any custom login flows. Each environment needs its own Entra ID application, because the SuiteCRM admin guide notes that SAML apps are unique to each instance. An existing configuration must be reviewed and updated, and the SuiteCRM 8 upgrade documentation requires that before upgrading to 8.7.0 or later. Role mapping grows with each team and permission set. A certificate process that is documented and owned by a team lowers risk. Custom login flows, such as step-up prompts or bespoke redirects, add testing and support work.
Which parts of SuiteCRM SAML are one-time and which recur?
The initial build is one-time: the Entra ID application, the SuiteCRM SAML settings, user matching, role mapping, testing and documentation. Recurring work follows the platform and the identity provider. Certificates expire and must be renewed on the identity provider and in SuiteCRM. SuiteCRM 8 minor releases arrive roughly every eight weeks, and each one should be tested for SAML login before it reaches production, since patch releases contain only security and bug fixes but still change the running system. Any change to role mapping or new environments also needs a test pass. Ask whether the scope includes these recurring tasks, or whether they move to a support arrangement.
Does signing out of Entra ID also end the SuiteCRM session?
No. In SuiteCRM 8.7.0 and later, the SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so signing out at Entra ID does not end the SuiteCRM session. Users who stay signed in to SuiteCRM remain signed in until the session expires or they log out in the CRM itself. Plan for this in your access policy and user guidance, and decide whether shared workstations need a shorter session length or a different control. Ask the provider to state this limitation in the scope and to describe what, if anything, will be done about it, rather than leaving it for users to discover after go-live.
What should a written scope for SuiteCRM SAML include?
A written scope should name each instance and its environment, the Entra ID applications to be created, the SuiteCRM SAML settings to be applied and the user matching method. It should also state how roles are mapped and who approves them, how certificates are issued, stored and renewed, and who owns each renewal. Testing should be defined by environment, with staging tested before production and a list of login scenarios. The scope should list documentation and handover, what is excluded (such as custom login flows or logout changes), what the client must supply and the people responsible for each. Finally, it should state which recurring tasks are included or excluded.
How DeployOpen scopes and delivers SuiteCRM SAML sign-on
DeployOpen plans and delivers SuiteCRM sign-on through Microsoft Entra ID as a planned change inside your own infrastructure, starting with a written scope. Engagements are fixed-scope, so the identity provider setup, SuiteCRM configuration, test evidence and handover are agreed before work begins.
How we scope
- Confirm which SuiteCRM 8 version and PHP, Apache and database versions your environment runs before choosing the SAML approach.
- Inventory every SuiteCRM instance so staging, test and production each get their own Entra ID enterprise application.
- Agree in writing how SuiteCRM usernames will match Entra ID email addresses and who maps existing accounts.
How we build
- Configure the Entra ID enterprise application with the Entity ID, Reply URL and Sign-on URL for each instance.
- Enable SAML with AUTH_TYPE=saml and set SAML2Authenticate per user, then test on staging before any production change.
- Document certificate rotation, the logout limitation and the procedure for handling users who sign out at Entra ID.
How we hand over
- Deliver a written configuration record covering each application, certificate, claim mapping and environment variable used.
- Provide test evidence for successful sign-in, rejected accounts and session behavior on each environment.
- Walk your administrators through the runbook, including what must be reviewed before any SuiteCRM upgrade.
How we support
- Offer ongoing support and upgrade work as a retainer, scoped in writing, for SAML changes after go-live.
- Review SuiteCRM release notes and SAML configuration changes with your team before each version move.
- Confirm with your team who owns certificate renewal, Entra ID changes and user offboarding after handover.
