How GLPI Entra ID SSO and SCIM provisioning work together
For an IT or identity team that wants Entra ID to control GLPI logins and the user lifecycle, the supported route is the OAuth SSO plugin for sign-in and the SCIM plugin for provisioning, and both depend on GLPI external authentication. The two plugins do different jobs. OAuth SSO handles the sign-in handshake: it lets a user authenticate with Entra ID and arrive in GLPI with an identity that GLPI accepts. SCIM handles the account lifecycle: the identity provider pushes users and group membership into GLPI so accounts exist before first sign-in and can be changed or removed when people join, move or leave. Neither plugin replaces the other, and removing one changes what the other can do.
Before any configuration, confirm with the vendor that your GLPI edition and subscription include the OAuth SSO and SCIM plugins, since the GLPI documentation for these plugins and the GLPI Network subscription terms determine what you may run in production. Ask the vendor which plugin versions match your GLPI 11 or 12 release, because external authentication settings and identifier handling are the parts most likely to change between versions.
This is an integration plan, not a single toggle. The team has to decide which Entra ID attribute becomes the GLPI login identifier, how profiles and entities are assigned, whether SCIM or sign-in alone creates the first account, and how the GLPI URL will be reached from Entra ID and from users. Each of those decisions affects the others, and the plan should record them together before the first test user signs in.
What you need in place before configuring Entra ID with GLPI
Most delays in Entra ID sign-in and SCIM provisioning for GLPI come from decisions made before anyone opens the plugin settings. The six items below cover the GLPI version, the URL model, the licensing, the Entra app ownership, the identifier attribute and the SCIM endpoint, and each one should be confirmed in writing before configuration starts.
A supported GLPI version
Plan on GLPI 11 or 12. GLPI 12.0.0 was released on October 7, 2026, and GLPI 11.0.11 on October 1, 2026. The installation docs for GLPI 11.0 list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, while the README for the main branch asks for PHP 8.3 or later with MariaDB 10.11 or MySQL 8.0. Confirm which set applies to the release you pick, since only MySQL and MariaDB are supported databases.
A reachable HTTPS URL
Entra ID can sign users in to a GLPI instance on a private HTTPS address, but Google and Okta accept only public HTTPS URLs. Decide the public or private URL model before you register the application, because changing the callback address later means updating the Entra app and the GLPI OAuth client together. Confirm that the URL GLPI generates matches the redirect URI registered in Entra exactly.
A GLPI Network tier with both plugins
The OAuth SSO and SCIM plugins are part of the GLPI Network offering, so the subscription is a recurring cost to plan for alongside the platform itself. The public subscriptions page lists public cloud, private cloud and self-hosted tiers, with the self-hosted tiers ranging from 100 euros per month to 4,500 euros per month. Ask the vendor in writing which tier includes both plugins for your deployment model and how it is renewed.
An Entra app registration and consent owner
Someone with authority in the tenant must create the app registration, set the redirect URI, create a client secret and grant admin consent for the permissions the plugin requests. Name that owner and a backup before work starts, and record the client secret expiry date so sign-in does not fail silently when the secret lapses. Keep the registration in the same tenant that holds the users you intend to provision.
An agreed identifier attribute
The OAuth SSO plugin relies on GLPI external authentication with the identifier usually set to HTTP_AUTH_USER. The docs warn that stripping the domain from identifier@domain can merge separate user records, which opens the door to identity theft. Agree on one identifier format, such as the full user principal name, before the first login, and decide how existing local accounts will be matched to it.
A SCIM endpoint with restricted sources
Entra ID must be able to reach the SCIM endpoint on your GLPI instance to push user changes. The SCIM documentation recommends restricting which IP addresses can reach that endpoint, so collect the outbound ranges the provisioning service uses and agree on the firewall or reverse proxy rule before enabling provisioning. Note that password sync is not available with Azure, so plan on OAuth SSO rather than pushed passwords.
Public versus private URL rules for Entra ID, Okta, Google and Keycloak
Entra ID accepts a private URL for the GLPI redirect URI, provided the address uses HTTPS. That means an internal-only GLPI host can keep its private name, as long as the certificate it presents is trusted by the browsers of the users who sign in and by the GLPI server that exchanges the authorization code. The OAuth SSO plugin still needs to reach the identity provider's token and metadata endpoints from the GLPI server, so outbound access matters as much as the inbound browser path.
- Scheme and host: Register the exact HTTPS redirect URI that GLPI generates, including the path, and do not rely on a wildcard you have not tested.
- Certificate trust: Confirm that the internal certificate chain is trusted by every browser and by the GLPI server's PHP certificate store.
- Outbound reach: Confirm the GLPI server can reach the Microsoft login endpoints it needs to complete the token exchange.
- Name consistency: Use one canonical GLPI URL in the plugin settings, the app registration and the GLPI base URL setting.
- Subscription check: Confirm that the OAuth SSO plugin's licensing requirements apply to your setup before you build the registration.
Before you register the redirect URI, open GLPI in a private browser session on the exact name you plan to use, confirm the certificate is valid, and confirm the GLPI server can resolve and reach the identity provider. Confirm the current redirect URI rules with Microsoft's Entra ID documentation for your app type.
Okta only accepts public HTTPS URLs for the GLPI redirect URI. An internal-only GLPI host cannot be registered as it is. The usual options are to publish GLPI under a public DNS name with controlled access, or to place a reverse proxy or publishing layer in front of GLPI that presents a public HTTPS name while the application stays private. Either way, the public name must resolve to a host the browser can reach and that forwards the callback to GLPI correctly.
- Public name: Choose a public DNS name and a certificate from a publicly trusted authority for the GLPI redirect URI.
- Forwarding: If you use a proxy, confirm it preserves the host header and the path GLPI expects, so the callback reaches the right application.
- Access control: Restrict who can reach the public name with network controls or identity-aware access, since the name is now exposed.
- Plugin settings: Set the GLPI base URL to the public name so generated links and callbacks match the registration.
- Design review: Record the decision, because a public name changes the exposure of the GLPI host and its login page.
Before you register the redirect URI, test the public name end to end from outside your network, confirm the certificate chain is publicly trusted, and confirm the callback returns to GLPI. Check Okta's current redirect URI requirements in its developer documentation, since its rules for URI formats can change.
Google only accepts public HTTPS URLs for the GLPI redirect URI, so the same design choice as Okta applies. A GLPI host reachable only on a private network cannot complete the Google sign-in flow directly. The practical routes are a public DNS name with a publicly trusted certificate, or a publishing layer that presents a public name and forwards only the GLPI paths needed for sign-in. Because the Google client is registered against that name, a later change of hostname means a new registration and new user links to verify.
- Domain ownership: Confirm you control the domain used for the redirect URI and can add it to the Google client configuration.
- Certificate: Use a publicly trusted certificate on the exact host name, with a valid chain.
- Scope of exposure: Expose only the sign-in and callback paths if you publish through a proxy, and keep administrative paths private.
- Consistency: Match the GLPI base URL, the plugin settings and the Google client redirect URI character for character.
- Organization policy: Confirm with your identity team whether your Google Workspace policies allow the client type and domain you plan to use.
Before you register the redirect URI, check that the public name resolves, the certificate is trusted from outside your network, and the callback path is reachable. Confirm the current redirect URI and domain verification rules with Google's OAuth documentation, since these pages change.
Keycloak accepts private URLs for the GLPI redirect URI as long as they use HTTPS. This allows an internal GLPI host with an internal certificate to be registered as a client, which is often the simplest design when Keycloak itself runs inside your network. The constraint moves to the certificate and to the reachability of Keycloak from the GLPI server, because the plugin calls Keycloak's endpoints server to server and the browser needs to reach Keycloak for the login step.
- HTTPS requirement: Use HTTPS on both the GLPI redirect URI and the Keycloak issuer URL, since private HTTP addresses are not accepted.
- Issuer reachability: Confirm the GLPI server reaches the Keycloak issuer and discovery endpoints using the same host name the browser uses.
- Trust store: Add your internal certificate authority to the trust stores of both the browser population and the GLPI server.
- Client settings: Register the exact redirect URI in the Keycloak client, and keep the valid redirect list as narrow as your sign-in flow allows.
- Keycloak version: Confirm the Keycloak version you run is supported for your deployment, since the upgrade cadence affects the client configuration you test against.
Before you register the redirect URI, confirm the GLPI server can fetch the Keycloak discovery document, confirm the certificate chain validates from a GLPI host and a user workstation, and test one sign-in end to end. Check the current client redirect URI rules in the Keycloak server administration documentation for your version.
Configuring GLPI Entra ID SSO and SCIM in order
This sequence takes GLPI from a confirmed public HTTPS address to a state where Entra ID signs users in through the OAuth SSO plugin and provisions them through the SCIM plugin. Each step closes with a check, so a failure is caught before the next layer depends on it.
Confirm the GLPI URL and HTTPS certificate
Your infrastructure team confirms the address users will type, the certificate chain that serves it and the web server document root that points to GLPI's public directory. Entra ID redirects users to this address, so it must be stable before any app registration is made. The check is that the URL loads over HTTPS in a clean browser session with no certificate warning.
Register the Entra app and redirect URI
Your identity team creates an app registration in Entra ID, records the tenant and client identifiers, creates a client secret and adds the redirect URI that the OAuth SSO plugin displays for your GLPI instance. Entra accepts private HTTPS URLs, so the address can resolve on your internal network. The check is that the redirect URI in Entra matches the value in GLPI character for character.
Enable external authentication with HTTP_AUTH_USER
A GLPI administrator enables external authentication in the GLPI configuration and sets the identifier field, which is usually HTTP_AUTH_USER, so the plugin can match the signed-in identity to a GLPI account. Do not strip the domain from identifier@domain at this stage, because the plugin documentation warns that doing so can merge separate user records. The check is that a test account can be matched by its identifier without creating a duplicate.
Install and configure the OAuth SSO plugin
A GLPI administrator installs the OAuth SSO plugin, enters the Entra tenant, client identifier and secret, and confirms the subscription requirement for your edition with Teclib' or your DeployOpen contact before go-live. The plugin settings are then saved and the sign-in button appears on the login page. The check is that the plugin configuration page shows the provider as enabled without error messages.
Test sign-in with a pilot account
A pilot user who holds a GLPI profile signs in through Entra ID from a browser session with no existing GLPI cookies. Confirm that the account is matched to the expected existing or newly created record, and that the user lands in the correct entity and profile. The check is a successful sign-in with a single user record and the audit entries for the login visible to an administrator.
Add the SCIM plugin and its endpoint
A GLPI administrator installs the SCIM plugin and generates the endpoint and token that Entra ID will use, then records where they are stored. The endpoint must be reachable from Entra's provisioning service, so network routing and firewall rules are reviewed at this point. The check is that a request to the endpoint with a valid token returns a response and an invalid token is refused.
Restrict source addresses to the identity provider
Your network team limits which source addresses can reach the SCIM endpoint, using the ranges the SCIM documentation recommends you restrict and the provider ranges your Microsoft contacts confirm for your tenant. Apply the restriction at the web server or firewall in front of GLPI. The check is that a request from an address outside the allowed list is blocked while Entra's test connection still succeeds.
Connect Entra ID provisioning and confirm the created profile
Your identity team sets the GLPI SCIM endpoint and token as the provisioning connection in Entra ID, maps user attributes, and assigns a small pilot group. Run a provisioning cycle, then confirm that the created GLPI user has the expected profile, entity and group membership. Note that Azure does not support password sync with SCIM in this integration, so passwords stay with Entra ID. The check is that the pilot user exists in GLPI with the intended profile and can sign in through SSO.
Why the identifier design decides whether user records merge
The identifier you map to GLPI's external authentication field decides whether two people can ever end up on the same user record. The OAuth SSO documentation notes that the plugin relies on GLPI external authentication, with the identifier field usually set to HTTP_AUTH_USER, and it warns that stripping the domain from an identifier@domain value can merge user records and is open to identity theft. The practical rule is to keep the full value that your identity provider asserts, including the domain, and to choose an attribute that is unique within the tenant and does not change when a person changes their display name, department or mail alias. Before go-live, confirm with your Entra administrator which claim or attribute the OAuth SSO configuration will send, and whether any user principal name can be reused after an account is deleted and recreated.
Test for collisions before any user signs in. Export the login names of every existing database account and every LDAP or Active Directory account that GLPI can already read, then compare them with the identifiers Entra ID will send for the same people, including accounts that were created by hand for service staff or former employees. Pay attention to case differences, to short names that match across two directories, and to accounts whose identifier is a bare username rather than an email-style value. Run the same comparison on a copy of the instance so that any merge is found in a test environment and not in the production user table.
The order of external authentication decides which account a login matches. The GLPI user documentation describes authentication against the internal database, LDAP directories, IMAP mail servers and other external methods such as REMOTE_USER, tried in that order. If a local account already uses the same login string as the identifier from Entra ID, the SSO sign-in can resolve to that local account, with its profile and entity rights, instead of a new federated user. Decide in advance which source is authoritative for each person, document that decision, and verify with test accounts that a federated login lands on the expected record and that the local administrator account remains a separate, known identity.
Mapping Entra ID attributes and groups to GLPI user fields
This table compares each Entra ID attribute or group with its GLPI target, the system that should own the value, and the decision your team must make before enabling sign-in or provisioning. Read it as a planning checklist: the source of truth column shows where a value should change, and the decision column shows what to settle with your identity and GLPI administrators. Confirm every exact attribute name against the current OAuth SSO and SCIM plugin documentation before you build the mapping.
| Entra ID attribute or group | GLPI field or profile target | Source of truth | Decision the team must make |
|---|---|---|---|
| User principal name or chosen login claim | External identifier used for login (typically matched to HTTP_AUTH_USER) | Entra ID | Pick one stable identifier and confirm whether the domain is kept, since stripping it can merge accounts |
| Mail attribute | User email address, updated by SCIM | Entra ID | Decide whether email is used for notifications only or also as a matching key |
| Given name and surname | First name and last name fields, updated by SCIM | Entra ID | Confirm which name source HR or the directory treats as authoritative |
| Account enabled flag | User active status, updated by SCIM when a user is disabled | Entra ID | Define how disabled users are handled: deactivate, keep history, or delete, and who approves it |
| Security group membership used for profile assignment | Profile assignment through GLPI rules, set at first login by the OAuth SSO plugin | Entra ID groups, mapped by GLPI rules | Choose which groups grant profiles and who owns each group, and decide the default profile for unmatched users |
| Group or organizational unit used for entity assignment | Entity assignment through GLPI rules | Entra ID groups or attributes | Decide whether entities follow department, location or a dedicated group, and document the rule order |
| Group membership for provisioning scope | Users provisioned into GLPI only when assigned to the Entra application | Entra ID enterprise application assignment | Agree who may request access and how removals are approved before the first sync |
| Password | No password sync from Entra ID | GLPI external authentication or Entra ID sign-in | Accept that Entra ID does not sync passwords into GLPI, and keep OAuth SSO as the sign-in path |
Security settings for SSO and SCIM in GLPI
Signing users in and provisioning them from Entra ID touches GLPI's authentication, its API surface and its stored secrets. The cards below cover the controls that connect those areas, and each one names a decision or check your team should record before go-live.
Restrict SCIM endpoint access
The SCIM endpoint has to be reachable by the identity provider, so it is exposed to the network by design. Limit which source addresses can reach it, using the address ranges your identity provider publishes or a reverse proxy allow list at the web server layer. Confirm with your network team which path the provisioning traffic takes and that no other clients can reach the same URL. Review the allow list whenever your provider or network layout changes.
Treat SCIM as a privileged interface
Anyone who can call the SCIM endpoint can create, change or disable user accounts, so it carries the authority of an administrator. Use a dedicated credential for the provisioning connector, scope it to the provisioning role only and store it in your secrets manager rather than in a script. Log and alert on SCIM activity, and include the endpoint in your access review and hardening scope.
Decide on forced SSO and break-glass
Forced SSO sends every sign-in through Entra ID, which is the right model when the identity provider is the system of record. It also means a broken federation or expired configuration can lock out every administrator. Decide in advance whether you keep a small set of local break-glass accounts, where their credentials are held, how they are tested, and who is alerted when one is used. Document the decision alongside your GLPI authentication model.
Prefer OAuth SSO over pushed passwords
The SCIM documentation recommends OAuth SSO instead of pushing passwords from the identity provider into GLPI. With OAuth SSO, GLPI relies on external authentication and the user's password never leaves Entra ID. Confirm this model with your security team before enabling any password-sync option, since it changes where credential material is stored and how it is protected.
Plan password handling by provider
Password sync is not available with Azure, but it is available with Okta. For an Entra ID deployment, that means GLPI will not receive password changes from the directory, so local password policy, lockout and reset flows have to be defined for any account that still signs in locally. Ask your team which accounts keep local passwords, who owns their reset process and how that process is recorded for audit evidence.
Protect encryption keys and backups
GLPI's update procedure requires backing up the config directory, including the glpi.key and glpicrypt.key files. Those keys protect data stored in the database, so a backup of the database without the keys cannot be fully restored, and a copy of the keys next to an unencrypted database export creates a single point of compromise. Store keys and backups in separate access-controlled locations, restrict who can read them, and test a restore that includes the key files.
Common Entra ID SSO and SCIM failures and their causes
This table pairs the failures most often seen when GLPI signs users in with Entra ID or provisions them with SCIM, with the likely cause and the first fix to try. Read each row against the symptom you see in logs or on the login page, then confirm the fix against the plugin documentation for your GLPI version. The main takeaway is that most failures trace back to URL rules, identifier mapping or source address limits rather than to Entra ID itself.
| Symptom | Likely cause | Fix |
|---|---|---|
| Entra ID returns a redirect URI mismatch error at sign-in | The redirect URI registered in the Entra app registration does not match the callback URL GLPI sends, often because of a different scheme, host, port or trailing path | Copy the callback URL exactly from the OAuth SSO plugin configuration into the app registration, then retest with a private browser session |
| The sign-in button is missing or the flow fails before reaching Entra ID | GLPI is served on a private or non-HTTPS URL that the OAuth SSO plugin rejects for the chosen provider | Confirm the provider rules in the OAuth SSO documentation; Entra ID accepts private URLs only when they use HTTPS, so serve GLPI over HTTPS with a valid certificate |
| A user signs in and lands on a second, empty user record | The identifier mapped to external authentication includes the domain (identifier@domain) in one source and not the other, so records do not merge | Map the identifier consistently, usually HTTP_AUTH_USER, and check for duplicates before go-live; the OAuth SSO documentation warns that stripping the domain can merge records unsafely, so review the design with your security team |
| SCIM calls from Entra ID fail or time out | The SCIM endpoint is reachable from Entra ID but blocked by source address restrictions on a firewall, reverse proxy or web application rule | Allow the Entra provisioning service source addresses you have confirmed with Microsoft, and restrict all other sources as the SCIM documentation recommends |
| Users are created but without the intended profile or entity access | No authorization rule matches the attributes sent by the identity provider, so GLPI applies its default profile | Review the rule conditions against the attributes actually received, then test with one pilot user before enabling broader provisioning |
| A password changed in Entra ID does not work in GLPI | Password sync is not available with Azure through the SCIM plugin, so GLPI never receives the new password | Sign users in with OAuth SSO instead of relying on pushed passwords; the SCIM documentation recommends this approach |
| SSO or SCIM stops working after a GLPI update | Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates | Reactivate the OAuth SSO and SCIM plugins in the plugin list, then rerun the login and provisioning tests before closing the change |
Questions buyers ask about GLPI Entra ID SSO and SCIM
Do the OAuth SSO and SCIM plugins need a GLPI Network subscription?
The OAuth SSO plugin requires a GLPI Network subscription, and you should confirm the same requirement for SCIM before you scope the work. The subscriptions page lists self-hosted plans from Basic at 100 euros per month, covering up to 10 agents and 500 assets, to Enterprise at 4,500 euros per month, which adds level 3 support and marketplace plugins. Cloud plans are priced per user: 19 euros per user per month for public cloud and 21 euros for private cloud, with a 25-user minimum for private cloud. Those are listed prices and they change, so check the GLPI Network subscriptions page and ask Teclib' which tier includes both plugins for your deployment.
How long does Entra ID SSO and SCIM provisioning take to set up?
No duration can be stated from the sources available here, so ask for an estimate tied to a written scope. The main drivers are the number of identity providers you connect, whether your GLPI URL is public or private (Entra accepts private HTTPS URLs, while Google and Okta require public ones), how much identifier clean-up your existing user records need, and how far testing goes. Duplicate accounts from identifiers like identifier@domain take longer to resolve than a clean directory. Ask for the phases, the testing matrix and the dependencies on your network and identity team in the quote.
What does our team need to provide before the engagement starts?
Your team needs administrative access to the Entra ID tenant to register the application and configure claims, and to the GLPI server and web server so the plugins and external authentication can be set up. You also need an agreed HTTPS hostname for GLPI, a decision on which user attribute will serve as the identifier, a named owner for group-to-profile mapping, and test accounts for each role. If SCIM is in scope, your network team must confirm that the identity provider can reach the SCIM endpoint and approve a source IP restriction. Ask the partner to list each item and its owner in the written scope.
Can our internal team implement GLPI SSO and SCIM without a partner?
Yes, an internal team can do this if it has identity engineers who can work in Entra ID and GLPI administrators who can manage external authentication, plugins and a database backup. The work is less about the plugin settings and more about the decisions: URL rules, identifier design, attribute mapping, the rule that assigns profiles, and how deprovisioning behaves. Many teams underestimate the testing of edge cases such as renamed users and duplicate records. A partner can take on the build, the test plan and the documentation under a fixed scope, while your team keeps ownership of the decisions and operations afterward.
Can SCIM sync user passwords from Entra ID into GLPI?
No. The GLPI SCIM documentation states that password sync is not available with Azure, which covers the Microsoft identity platform in this context, while it is available with Okta. GLPI's documentation also recommends OAuth SSO over pushing passwords, so the usual design is that users authenticate against Entra ID and GLPI never receives a password. SCIM handles user and group provisioning in that model. Confirm the current behavior with Microsoft and GLPI before you finalize the design, because platform support can change between releases.
How does the work differ for Keycloak or Okta compared with Entra ID?
The main differences are the URL rules, the SCIM password behavior and the identity platform's own configuration. Entra ID and Keycloak accept private HTTPS URLs for GLPI, while Google and Okta accept only public HTTPS URLs, which can change your network design. Password sync through SCIM is available with Okta but not with Azure. Keycloak is self-managed, so you also plan its database, high availability and upgrade cadence, and its SCIM support should be confirmed for your version before you commit to a provisioning design. Ask for a separate section per provider in the quote.
What security checks matter most before going live with SSO?
The most important check is identifier handling. The OAuth SSO documentation warns that stripping the domain from identifier@domain can merge user records, which is open to identity theft, so you should verify that every identifier is unique and tied to a verified account before you enable automatic user creation. Next, confirm that the SCIM endpoint is reachable only from the identity provider's addresses, and test forced SSO, profile assignment and the behavior when a user is disabled in the directory. Ask the partner to show these tests in the test plan, along with the backup steps for the GLPI encryption keys.
How DeployOpen works on this
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For GLPI sign-in and SCIM provisioning, we start with a written scope that fixes the identity provider, the URL model, the subscription position and the attribute rules before any configuration changes are made.
How we scope
- Confirm which identity provider you use (Entra ID, Okta, Google or Keycloak) and whether GLPI is reachable on a public or private HTTPS URL.
- Confirm the GLPI Network subscription position needed for the OAuth SSO and SCIM plugins before design begins.
- Agree in writing the user attributes, profile assignment rules, password handling and the IP restrictions for the SCIM endpoint.
How we build
- Configure GLPI external authentication with the identifier field, and test how identifier@domain values map to existing user records.
- Register the Entra ID enterprise application or equivalent client, set redirect URLs and map claims to GLPI attributes in a non-production instance first.
- Test SCIM create, update and deactivate events end to end, including group and profile assignment, before any production cutover.
How we hand over
- Document the URL model, client registration details, attribute mapping and every external authentication setting with its owner.
- Record the password sync limits for your identity provider so that account policy decisions are made and written down.
- Provide a runbook for rotating client secrets, reviewing SCIM logs and reactivating plugins after GLPI version upgrades.
How we support
- Support is available as a retainer covering plugin updates, GLPI 11 and 12 upgrade checks and changes to identity provider configuration.
- Plan each change to the SSO or SCIM setup as a fixed-scope piece of work with written deliverables and timelines.
- Re-test sign-in, provisioning and deprovisioning after each GLPI, plugin or identity provider change that affects these flows.
