How GLPI SCIM provisioning with Okta keeps accounts in step with your directory
Sign-in alone does not create or remove GLPI accounts. A team that only connects Okta to GLPI for login still depends on someone to create a user record before a new joiner can work, to change profiles when a person moves between departments, and to deactivate the account when they leave. SCIM provisioning moves those lifecycle events out of GLPI's administration screens and into the identity provider, so that a change made once in Okta is pushed to GLPI as a create, update or deactivate request. The gap matters most for leavers, because an account that stays active after the person has gone is the kind of finding that compliance reviewers and internal auditors look for first.
The method in scope for this topic is the SCIM plugin for GLPI, which exposes a SCIM endpoint that Okta calls to manage users and groups. Before design starts, confirm the plugin's exact name, the GLPI versions it supports, and how its endpoint handles users and groups, using the plugin's own documentation and the GLPI version you run or plan to run. Do not assume that a plugin release written for GLPI 10 works on GLPI 11 or 12, since plugins are suspended after a new version is detected and must be reactivated after major updates. Also confirm which Okta provisioning features your Okta tenant and license include, because feature availability varies and the GLPI side can only accept what the plugin implements.
Two decisions shape the rest of the design. First, decide which Okta attributes become the GLPI login, email and group membership, since these values later drive profile and entity assignment and must stay stable across renames. Second, decide who owns the mapping and who approves changes to it. Ask the plugin's maintainer or your integrator to confirm how it treats users that already exist in GLPI from a local or directory source, so that a SCIM push does not create duplicate accounts. Record these answers before any test tenant is connected, because they determine the verification plan and the operating checks described later on this page.
What you need before connecting Okta to GLPI
Six items need to be in place before anyone configures provisioning. Each one depends on a version, a network path or a permission that differs between environments, so confirm them in writing before the build starts. Together they decide whether the SCIM endpoint can be tested safely and rolled back if provisioning misbehaves.
A supported GLPI release
Confirm that your GLPI 11 or 12 instance meets the prerequisites in the installation docs, including the PHP version and a supported database. GLPI 11.0 lists PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, while the main branch README lists PHP 8.3 or later with MariaDB 10.11 or MySQL 8.0. Use the higher requirement when planning, and confirm that the document root points to the public directory. Check the version against the SCIM plugin before anything else.
SCIM plugin compatibility
Do not assume a SCIM plugin supports your GLPI version. Confirm the plugin release, its supported GLPI versions, and whether it exposes the user and group resources you need for Okta. Record the plugin version in your change ticket, because plugins are suspended after a new GLPI version is detected and must be reactivated after major updates.
Okta tenant and provisioning rights
You need an Okta administrator who can create a custom or supported application, enable provisioning, and assign users and groups to it. Confirm in the Okta admin documentation how SCIM provisioning is enabled for your tenant edition and which push options are available. Decide early who owns the application, because changes made by a single administrator are hard to audit later.
Reachable hostname and TLS certificate
Okta must reach the GLPI SCIM endpoint over HTTPS, so decide whether it is published on a public hostname or through a private connection that Okta can use. Confirm that the certificate chain is trusted by Okta and that the hostname matches the one GLPI is configured to use. Test the path from outside your internal network, since a working internal URL does not prove that Okta can connect.
Service account and credential policy
Plan a dedicated GLPI account for the SCIM integration with the narrowest profile the plugin accepts. Decide how the bearer credential or token is generated, stored, rotated and revoked, and who approves each change. Confirm with the plugin documentation how the credential is presented and whether it can be restricted by source address, since that determines how you limit access to the endpoint.
Test instance and verified backup
Run the first configuration against a test GLPI instance that holds a recent copy of production data or realistic sample data. Take a backup of the database, files and config directory, including glpi.key and glpicrypt.key, before any change. Confirm that you can restore to that backup, because a bad provisioning run can deactivate or move many accounts at once.
Configuration sequence for SCIM provisioning from Okta
This sequence connects Okta to GLPI for user and group provisioning in stages, with a check at each step. It starts with a verified backup and ends with a pilot group whose users, deactivations and sessions match what Okta sends.
Confirm versions and back up GLPI
The GLPI administrator confirms the GLPI release, the PHP and database versions, and the SCIM plugin release that matches that GLPI version, using the plugin's compatibility notes. Before any change, back up the database, the application files and the config directory, including glpi.key and glpicrypt.key, following the GLPI update documentation. Keep the backup outside the GLPI host. This step is done when a copy of the database restores to a test server and GLPI starts there using the same keys.
Install and activate the SCIM plugin
On a non-production copy of GLPI, the administrator installs the SCIM plugin from the plugin list and activates it. Run any database update the plugin requires and check the plugin's configuration page loads without errors. Repeat on production only after the test copy behaves as expected. This step is done when the plugin shows as active and its settings page opens for an administrator with the right profile.
Reactivate plugins after upgrades
Since GLPI 11, plugins are suspended when GLPI detects a new version, and they must be reactivated after major updates. Whoever runs upgrades adds a reactivation step to the change record, so the SCIM plugin is not left suspended after a GLPI update. Check each plugin's status after every core update, including the SCIM plugin. This step is done when the SCIM plugin is active again and the endpoint test in the next step succeeds.
Configure the SCIM endpoint and credential
The administrator creates a dedicated GLPI account for provisioning with the smallest profile that can manage users and groups, then generates the credential the plugin uses. Confirm the endpoint path, the authentication method and the exact fields in the plugin documentation before entering them. Limit reachability of the endpoint to Okta's published source ranges at the reverse proxy or firewall. This step is done when a request with the credential returns the expected success response, and the same request without a credential is refused.
Create the Okta application and provisioning settings
In Okta, the administrator creates an application integration for GLPI, enables SCIM provisioning, and enters the base URL and credential from the previous step. Turn on the provisioning actions you plan to use, such as creating users, updating attributes and deactivating users. Okta's connection test is the first check on the link between the two systems. This step is done when Okta's test of the connector reports success and no warnings about authentication or reachability.
Map attributes and set push and deprovisioning
Map the Okta user name to the GLPI login, then map email, given name, family name and the active status. Decide whether leavers are deactivated or deleted, and document that choice, because deletion in GLPI affects ticket and asset history. Confirm how group membership is pushed, since authorization assignment is handled in a separate rule set. This step is done when Okta's attribute preview shows the expected values for a sample user and the deprovisioning choice is written down.
Test with a single user
Assign one test user in Okta and let the push complete. In GLPI, check the account exists with the expected login, email and name, and that it has no access beyond the profile and entity your authorization rules give it. Then unassign the user in Okta and confirm the account is deactivated in GLPI. This step is done when both the creation and the deactivation appear in GLPI as expected, and the results are recorded with the test date.
Widen to a pilot group
Assign a small pilot group in Okta and compare the number of users and memberships in GLPI with the Okta group. Make one membership change and confirm it reaches GLPI. On GLPI 12.0.0 and later, review the active sessions view for leftover sessions of a deactivated test user and revoke them if present. Confirm the same checks on your current GLPI release before expanding. This step is done when counts match, membership changes propagate and no deactivated test user keeps an active session.
Which Okta attributes become GLPI users, groups and profiles
This table maps the Okta attributes and groups that SCIM sends to the GLPI fields and objects they populate, with the owner of each decision and the failure it causes if wrong. Read each row as a question to settle with the plugin's mapping reference before go-live. The main takeaway is that identity fields are cheap to get right early but expensive to correct after users, tickets and assets have been attributed to the wrong accounts.
| Okta attribute or group | GLPI field or object | Who owns the decision | What breaks if it is wrong |
|---|---|---|---|
| Login name (userName) | User login name, which is the unique key GLPI uses to match an account | Identity team, with GLPI admins consulted | Duplicate accounts or ticket history attached to the wrong person after a rename |
| Primary email | User email address used for notifications and ticket follow-ups | Identity team and service desk owners | Notifications go to stale or shared mailboxes and password reset mail fails |
| First and last name | User firstname and realname fields shown in tickets and asset assignments | HR data owner via Okta profile | Requesters appear with wrong names on tickets, approvals and assigned assets |
| Active status | User active or inactive state, which controls whether the account can sign in | HR and identity team, driven by the leaver process | Leavers keep access, or active staff are locked out after a sync error |
| Okta group membership | GLPI group objects that the plugin creates or links to users, to confirm in the plugin's mapping reference | Identity team defines groups, GLPI admins approve use | Groups used for ticket routing or asset visibility stop matching real teams |
| Department, job title or location attributes (if sent) | Inputs to GLPI authorization assignment rules that choose profile and entity, a separate workstream | GLPI admins own the rules, identity team owns the source data | Users land in the wrong profile or entity, exposing or hiding assets across sites |
| Custom Okta attributes used for access | Only fields the plugin documents; confirm each name before use | Identity architect with GLPI admin sign-off | Silent mismatches where a renamed attribute stops updating GLPI records |
Password sync and where credentials actually live
SCIM provisioning moves user records, not passwords. Okta creates, updates and deactivates the GLPI account, and the directory keeps the authentication secret. Password synchronization is a different mechanism: it copies or forwards a password change to another system. Those two behaviors are easy to confuse in a planning meeting, and the difference decides where a credential lives. Before the build starts, decide which of three models applies to SCIM-provisioned users: GLPI accepts Okta-managed passwords through an external sign-in method, the accounts sign in through an external method with no local password at all, or GLPI stores a locally managed credential that the integration must maintain. Each model changes your password rules, your recovery process and your audit evidence.
The risk that matters most is the local password that outlives the person. If an account keeps a usable GLPI password after the user leaves, a deactivation in Okta may not stop access to the database-backed login path, and an attacker or former employee can still sign in if the account remains active or the password is reused elsewhere. Confirm with the SCIM plugin and Okta, in writing, three things: whether a password change in Okta is pushed to GLPI at all, whether a deactivation sets the GLPI user to inactive or only removes group membership, and what happens to sessions that are already open. Test each case with a disposable account before any production user is provisioned. Password rules for local accounts are configured separately in GLPI, so a policy set in Okta does not automatically apply inside GLPI. Any credential the integration itself uses to call GLPI must be treated as a secret, stored under the protections described in the GLPI installation documentation, including the encryption keys in glpi.key and glpicrypt.key, and included in your key backup and rotation plan.
Restricting who can reach the SCIM endpoint
A SCIM endpoint can create, change and disable GLPI accounts, so it needs the same protection as an administrative interface. The cards below cover network reach, credentials, trust in request headers, web server layout, administrator rights and monitoring, and they should be reviewed together before the Okta integration goes live.
Limit network reach to Okta
Allow inbound requests to the SCIM path only from the provisioning addresses Okta publishes, or route Okta traffic through a controlled egress point such as a reverse proxy or firewall rule that you own. Confirm the current address list with Okta before writing rules, because it can change and a stale list breaks provisioning silently. Test both a permitted and a blocked source before go-live.
Use a dedicated least-privilege credential
Create a separate GLPI API or SCIM credential for Okta rather than reusing an administrator's token. Scope it to the profile and entity it needs, record a named owner, and set a rotation date that the owner tracks. Confirm with the plugin documentation which credential types it accepts and how rotation is performed without a service interruption.
Do not trust client forwarding headers
If GLPI sits behind a reverse proxy, decide which proxy headers GLPI will trust and make sure only your proxy can set them. A client that can send its own forwarding headers may appear to come from an allowed address and bypass the network rule above. Strip or overwrite these headers at the edge, and test with a request that sets them yourself.
Restrict the SCIM path at the web server
Apply an access rule to the SCIM route in Apache, Nginx, lighttpd or IIS while keeping the document root on GLPI's public directory, as the installation docs require. The restriction should match only the SCIM path so the rest of the application keeps its normal behavior. Verify that URL rewriting still routes SCIM requests through index.php after the rule is added.
Review super-admin rights during rollout
During the rollout, list every account that holds super-admin rights and remove any that are not needed for daily work. Okta should provision users into profiles that cannot change global configuration, and the team should confirm that the SCIM account cannot grant itself wider access. Repeat this review after each GLPI upgrade, since role changes can appear with new versions.
Check sessions and step-up with automation
GLPI 12.0.0 adds a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Confirm with the vendor and in a test instance whether revoking a session affects automated provisioning, and whether step-up prompts can block a SCIM-driven change. Document the answer before enabling the integration on a production version.
Log and alert on SCIM failures
Forward web server access logs for the SCIM path and GLPI's own event logs to your central logging platform. Alert on repeated authentication failures, requests from unexpected addresses, and provisioning errors that stop user changes from reaching GLPI. Agree who receives each alert and how quickly they must respond, so a blocked Okta sync is noticed before leavers keep access.
Common SCIM provisioning failures and how to clear them
Each row pairs a condition to check with the fix to try and the verification step in the setup sequence that confirms it. Treat every cause as something to confirm in your own environment, since the same symptom can have several origins. Work through the rows in order when a first sync fails, because later rows often depend on the endpoint and credentials being correct.
| Failure | Condition to check | Fix and verification step |
|---|---|---|
| Okta cannot reach the endpoint | The GLPI SCIM URL is reachable from the public internet or from Okta's outbound addresses, and no firewall, reverse proxy or WAF blocks the SCIM path. | Confirm the path from outside your network, then re-run the connection test in Okta. Verify with a request to the endpoint from an approved test host before changing Okta settings. |
| TLS or certificate chain errors | The certificate served for the GLPI hostname includes all intermediate certificates, is not expired and matches the hostname Okta calls. | Install the full chain on the web server and re-test. Verify by checking the chain from an external client, then confirm Okta accepts the connection test. |
| Rejected credentials | The API client or token configured in the SCIM plugin is active, has not expired and is the one entered in the Okta application settings. | Regenerate the credential in GLPI, update Okta, and repeat the connection test. Verify that a single test request returns a success response before running any sync. |
| Duplicate users created | The attribute Okta sends for matching (for example the username or email) differs in format from the value stored in GLPI, such as case, domain prefix or alias. | Align the mapped attribute on both sides, then clear the duplicates in GLPI. Verify with a test user that updates in place rather than creating a second record. |
| Deactivated users still able to sign in | Okta sends the deactivate operation for the user, and the GLPI account reflects the disabled state after the sync cycle completes. | Check the user's status in the SCIM log and in GLPI, then confirm the login method used by the user is also governed by the directory. Verify with a test deactivation before relying on it for leavers. |
| Group membership not updating | Groups are pushed to GLPI as part of the Okta assignment, and the group's members are included in the push request. | Re-push the group from Okta and check the membership in GLPI. Confirm that authorization rules assign the expected profile and entity after the group changes. |
| Plugin suspended after a GLPI upgrade | GLPI reports the SCIM plugin as suspended following a version change, which GLPI 11 applies to plugins after a new version is detected. | Reactivate the plugin after the update completes, then confirm the database update ran. Verify by sending a test request to the endpoint after reactivation. |
| Rate or timeout issues during the first full sync | The initial push includes a large number of users and groups, and requests time out or return throttling responses in the Okta system log. | Limit the initial assignment to a small pilot group, then expand in stages. Verify that each stage completes without errors and that GLPI web server and database response times stay within normal limits during the run. |
Questions teams ask before connecting Okta to GLPI
Can our team connect Okta to GLPI without outside help?
Yes, if the team already has the right skills and time to test. The work needs someone comfortable with Okta administration (applications, groups, user attributes and provisioning settings), someone who administers GLPI profiles, entities and authorization rules, and someone who can configure the web server and TLS, because Okta must reach the SCIM endpoint over HTTPS. Installing plugins and running the GLPI update procedure also requires command line work with PHP. Teams new to both platforms should build and test in a non-production environment first, since a mapping mistake can create, change or deactivate production accounts. A written test plan with leaver and department-change cases is the step most often skipped when teams work alone.
What drives the cost of an Okta to GLPI SCIM project?
Scope drives cost. DeployOpen does not publish a price list. A quote follows from a written scope that lists the work to be done. The main components are the number of Okta applications and GLPI instances in scope, the number of groups and how they map to GLPI profiles and entities, the number of attribute mapping rules and exceptions, the number of environments (test, staging and production), and the test effort for create, update, deactivate and group-change scenarios. Plugin installation, configuration and security review are one-time items. Plugin upgrades, GLPI version moves and any support retainer recur. Ask each quote to separate one-time and recurring costs, name who performs each step, and list the test cases included.
How long does an Okta SCIM integration for GLPI take?
No duration applies to every environment, so the timeline is set by the written scope. The factors that move it most are how well the Okta group structure is already defined, how many environments must be built and tested, whether GLPI is already on the target version and whether installed plugins need compatibility checks, the change windows available for production, and how quickly the client approves the attribute and group mapping. Most engagements are fixed-scope, so the agreed milestones and timelines are written down before work starts. Ask for a schedule with milestones tied to sign-offs, so delays in approvals are visible.
What must we provide before the integration work starts?
Four things need to be in place before build work starts:
- Okta administrator access with rights to create and manage applications, groups and provisioning settings.
- Ownership and admin access to the GLPI environment, including the database, the web server and the config directory.
- Network and certificate ownership: the firewall and DNS decisions for the path Okta uses to reach the SCIM endpoint, and the party that issues and renews the TLS certificate for the GLPI hostname.
- Sign-off on the attribute and group mapping, plus test accounts and a named approver who can confirm results.
If any of these sit with a third party, such as a network team or an Okta tenant owner, confirm that party's involvement in the written scope before the schedule is set.
Does SCIM replace LDAP or SSO in GLPI?
No. SCIM handles account lifecycle: it creates, updates and deactivates users and groups from Okta. Sign-in is a separate decision. GLPI's 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. Teams often use SCIM to keep accounts current and SSO or directory authentication for sign-in, and they keep a local administrator path for recovery. Confirm with the GLPI authentication documentation how the chosen sign-in method interacts with accounts created by provisioning, including which method is tried first for a given user.
What ongoing work remains after go-live?
Several recurring tasks remain. Plugins need attention after each GLPI move: in GLPI 11, plugins are suspended after a new version is detected and must be reactivated after major updates, so the SCIM plugin's compatibility should be checked before every version change. GLPI released 11.0.11 on October 1, 2026 and 12.0.0 on October 7, 2026, so teams on 11 will face a planned move. The update procedure requires backing up the database, the files and the config directory, including glpi.key and glpicrypt.key, replacing the application files, and running php bin/console db:update. Okta group changes also need mapping reviews, and access reviews should check that leavers are deactivated. Ask the quote to state which of these are included and which need a retainer.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted GLPI inside your own infrastructure, including the Okta and SCIM provisioning path. The work starts with a written scope that fixes what is connected, tested and handed over before any configuration begins.
How we scope
- Inventory your Okta tenant, GLPI version, database and web server layout before agreeing the provisioning design.
- Agree in writing which user and group attributes flow from Okta, which GLPI profiles and entities they map to, and which accounts stay local.
- Confirm the SCIM endpoint exposure model, the authentication method for the connection and who owns the Okta application and the GLPI plugin configuration.
How we build
- Install and configure the SCIM plugin on your GLPI instance, following the vendor documentation for your exact GLPI release.
- Configure the Okta application, attribute mappings and group pushes in a non-production GLPI copy before any live tenant changes.
- Test create, update, deactivate and group membership changes, plus the endpoint restrictions, and record the results as part of the deliverables.
How we hand over
- Document the configuration, mappings, rule dependencies, credential locations and the runbook for rotating the SCIM credential.
- Walk your identity and GLPI administrators through the provisioning flow, the failure modes and the checks they should run after a change.
- Deliver the test evidence and a list of open items that remain with your team after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing separately from the initial engagement.
- Plan re-testing when you upgrade GLPI or change the Okta application, since plugin and version changes can affect the SCIM path.
- Confirm with your team who approves changes to the SCIM endpoint and how those approvals are recorded for audit purposes.
