Exposing GLPI SCIM and API endpoints safely

Why exposing GLPI SCIM and API endpoints safely needs a narrow path

Publish only the specific endpoints that an identity provider or integration calls, and place each one behind controls that restrict source addresses, OAuth client scope and visibility. The rest of GLPI should stay reachable only from the networks your staff already use. Teams usually need this path when a cloud directory provisions users into GLPI through SCIM, or when an external system creates or updates tickets and assets through the API. They usually do not need it when GLPI is used only by staff on the internal network or through a VPN, because the existing network boundary already limits who can reach the application. In that case, the work is confirming that no integration quietly depends on a public route.

A SCIM endpoint can create, change and deactivate user accounts, and an API client can read or change tickets and assets, so each exposed path carries significant authority over your data. Before you open anything, confirm the exact SCIM and API paths for your GLPI version in the GLPI documentation, and check whether the SCIM capability in your version comes from the core or from a plugin. Do not assume a path from an older release or from a vendor example. The GLPI 12.0.0 release notes are a useful starting point for what changed, but they do not replace testing against your own instance.

Make three decisions before any route is published: which identity provider or integration gets each endpoint, which OAuth2 client and scope it uses, and which source addresses may reach it. Assign an owner for the reverse proxy rules, since the same web server serves the rest of GLPI. Then decide how access is logged and who reviews those logs, so a blocked request, a new client or an unexpected source is visible. Test the restriction from outside your network before go-live, and repeat the test after each upgrade, because a new GLPI version can change paths.

Which exposure control fits each integration

This table compares the controls you can combine to publish GLPI's SCIM and API routes to identity providers and integrations. Read each row for what it guards against, what it costs to keep working, and the integration pattern where it fits best. Most deployments combine several rows, and the strongest default is a narrow path allowlist plus scoped OAuth2 clients with logging.

Control	What it protects against	What it breaks or costs to maintain	When it fits
Source IP allowlist at the reverse proxy	Requests from unknown networks reaching GLPI at all, including credential guessing from the internet	Provider egress addresses change, so the list needs an owner and a review schedule; confirm current ranges in each vendor's own documentation	Identity provider or integration calls come from stable, published addresses
Path-level allowlist for SCIM and API routes only	Exposure of the web login page, admin pages and other GLPI paths to callers that only need provisioning or API access	Rules must match the exact SCIM and API paths for your GLPI version; new paths added by upgrades or plugins need review	You want provisioning and API traffic reachable while the interactive interface stays private
Scoped OAuth2 client per integration	A leaked token exposing more data or actions than the one integration needs	Each client needs its own setup, scope review and rotation; overlapping clients make audits harder	Several integrations share one GLPI instance and need different rights
Private connector or VPN for integrations in the same cloud	Public exposure of the endpoint entirely, since traffic never crosses the internet	Network routing, DNS and certificate handling add setup work; confirm whether your provider supports private connectivity for the specific service	The integration runs in your own cloud account or on-premises network
Request logging at the reverse proxy	Undetected abuse, failed login spikes and unexpected callers; supports incident investigation	Log storage grows with traffic; logs must avoid recording tokens or personal data in full	Any exposed endpoint, since logs are needed to show who called what
Application logging in GLPI	Changes made through the API or SCIM without a clear actor, and unexplained account or group changes	Requires confirming which events GLPI records for API and provisioning actions in your version; retention is set by you	You need to tie a record change to a specific OAuth2 client or provisioning run

What the GLPI documentation confirms about its API surface

The first thing to rely on is the web server layout. GLPI's installation documentation requires the web server's document root to point to the public directory rather than the installation root, with URL rewriting routing requests through index.php on Apache, Nginx, lighttpd or IIS. That means the installation root, the config directory and the key files such as glpi.key are not meant to be reachable over HTTP at all. Before you publish any endpoint, confirm on your own host that a direct request for a configuration file or a file outside the public directory returns nothing useful. If the document root is wrong, no IP restriction on the API path will close the gap, so treat this check as the baseline for everything that follows.

The second point concerns the account that integrations will use. GLPI 12.0.0 added a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Both matter when an integration account holds broad rights, because a token or session tied to that account can reach far more data than the integration needs. Confirm which of these controls apply to API-issued access in your version, and whether revoking a session also invalidates OAuth-issued access, before you rely on them as a containment step. Plan to grant the integration only the profile and entity rights its job requires, since the console controls cannot narrow what a broadly privileged account can already do.

The third point is what the documentation does not settle. The exact SCIM endpoint paths, the OAuth2 client configuration screens and the supported grant types must be confirmed against the GLPI version you run and against any plugin that provides SCIM or OAuth2 features, because those details can differ by release and by plugin. Ask your implementation partner or the GLPI maintainers to show each path and grant type in your build, and record the results in your change ticket. Do not publish a route to a cloud identity provider until those values are written down for that exact version.

How to scope access for each integration type

The identity provider needs to create, update and deactivate users and group memberships through the SCIM endpoint, and nothing else. Its OAuth client should reach only the provisioning resources, with no administrative profile and no access to unrelated inventory or tickets.

Minimum rights: user and group management limited to the entities and profiles your attribute mapping requires. Do not grant an administrative profile.
Endpoints: only the SCIM resources for users and groups, plus the discovery documents the provider requests on connection.
Write access: yes, for user and group records. Confirm how deactivation is handled in your version, whether accounts are disabled or removed.
Source paths: allow only the outbound addresses of the provider's provisioning service, or a private connector path if you run one.
Review cadence: review mapped groups and client grants on a fixed schedule, such as each quarter, and after any change to your directory structure.

Before go-live, confirm that a test user created in the provider lands only in the expected entity and profile, and that a removed user loses access in GLPI within the window your provider documents.

How to publish the endpoints in order

This sequence takes GLPI's SCIM and OAuth2 API from a list of integration needs to a published, logged and reviewed set of endpoints. Each step ends with a check, so the team can confirm the exposure is limited before the next step begins.

Back up keys and configuration first
Before any change to the web server or reverse proxy, the platform owner copies the GLPI database, application files and the config directory, including glpi.key and glpicrypt.key. The GLPI update documentation treats these keys as required for recovering stored credentials and encrypted data, so they belong in the same backup set. Done means the backup has been restored to a separate test location or verified by a checksum, and the team has recorded where the copy lives.
Inventory the endpoints each integration needs
The integration owner lists every system that will call GLPI, such as a cloud identity provider sending SCIM provisioning requests or a reporting tool calling the REST API. For each one, record the HTTP methods, the paths and the data it reads or writes. Done means a written table exists with one row per integration, and any path not in that table is treated as out of scope.
Confirm endpoints against the installed version
The platform owner checks each path in the GLPI documentation for the exact version in production, not the latest release notes, because endpoint behavior and OAuth2 settings can differ between GLPI 11 and GLPI 12. Anything the documentation does not clearly describe goes on a list to confirm with Teclib' or with a test instance. Done means every path in the inventory is matched to a documented endpoint for that version, or flagged as unverified.
Create one scoped OAuth2 client per integration
The GLPI administrator creates a separate OAuth2 client and a dedicated service account for each integration, granting only the rights that the endpoint inventory requires. Shared clients and broad administrator accounts make it impossible to revoke one integration without breaking the others. Done means each client appears in GLPI with a name tied to its integration, and a test token from one client is rejected when used against a path that client should not reach.
Restrict paths and source addresses at the proxy
The infrastructure team configures the reverse proxy to forward only the documented SCIM and API paths, and only from the source addresses or ranges that the identity provider or integration platform uses. Every other request, including requests to the GLPI login page and administrative paths, receives a denial at the proxy. Done means the rule set is stored in version control and the proxy configuration reloads without errors.
Test permitted and refused requests
The integration owner sends a permitted request from an approved address and confirms that it succeeds with the expected status code and data. The security engineer then sends the same request from an address outside the allowlist, and a permitted request to an unlisted path, and confirms both are refused at the proxy. Done means the results are recorded as a test log that can be repeated after each configuration change.
Enable and retain proxy and GLPI logs
The platform team turns on request logging at the proxy, with source address, path, method, status and timestamp, and sends the logs to a store that the security team can search. The team also reviews GLPI's own logs for the integration service account, checking for failed authentications and unexpected actions. Done means a test request appears in both log sources with matching timestamps, and the retention period has been confirmed with the organization's logging policy.
Schedule recurring reviews of clients and allowlists
The owner of each integration confirms on a recurring schedule that its OAuth2 client, service account rights and source address allowlist still match a living need. Clients for retired integrations are revoked, and any address ranges that changed on the provider side are updated in the proxy through the same version-controlled process. Done means the review cadence is written into the operations calendar with a named owner, and the last review result is recorded.

Security risks to close before the endpoint is reachable

Publishing SCIM or the OAuth2 API turns a internal GLPI service into something an external identity provider or integration can reach. The risks below are the ones that most often turn a narrow integration into broad access, and each one has a control and a check you can run before the endpoint goes live. Close them in this order so that every later test runs against the final exposure.

Shared OAuth client across integrations

When several integrations use one OAuth client, a single leaked secret grants every integration's access and makes it impossible to tell which system made a given API call. The control is one client per integration, each limited to the scopes it needs and mapped to its own GLPI API account. The check is to list every OAuth client in GLPI, confirm each has one named owner and one integration, and revoke any client that no current integration uses.

Integration account with administrator rights

Many integrations are configured with an administrator profile because it is the fastest way to make requests succeed. That turns a provisioning connector into a full administrative credential for GLPI. The control is a dedicated service profile with rights only to the objects the integration reads or writes, such as users and groups for SCIM. The check is to run the integration's typical requests under that profile and confirm that out-of-scope requests return an access error.

Web root exposing installation files

If the web server serves the GLPI installation root instead of its public directory, files such as configuration and key files can be requested directly by anyone who can reach the host. The installation docs require the document root to point to the public directory with URL rewriting in place. The check is to request paths for the config directory and the key files from outside the network and confirm each returns a not-found or access-denied response, while the API path responds as expected.

Reverse proxy forwarding every path

A reverse proxy configured to forward all paths to GLPI exposes the login pages, administration screens and status output alongside the API. The control is an explicit allowlist of the SCIM and API paths the identity provider needs, with every other path denied at the proxy. The check is to send requests to administrative and login paths through the public hostname and confirm the proxy rejects them, and to confirm the allowed paths still complete a test provisioning call.

Stolen tokens without rotation

Access tokens that never expire or are never rotated stay useful to an attacker indefinitely after they are copied from a log, a config file or a developer laptop. Set a rotation procedure for client secrets and tokens before go-live, and confirm the token lifetime your GLPI version enforces rather than assuming a value. The check is to revoke a test token, confirm that the next request fails, and confirm that the procedure names an owner and a schedule for replacing the client secret.

Allowlist with a broad cloud range

Allowing an entire cloud provider's address range to reach the endpoint lets any tenant on that provider send requests that reach your GLPI host. Restrict the allowlist to the outbound addresses your identity provider publishes for its provisioning service, and record the source of each address. The check is to send a request from an address outside the list and confirm it is refused, and to review the allowlist each time the provider publishes changes.

How to log and review API access without collecting too much

Log the fields that let you tie a request to a specific integration and decide quickly whether it was expected: the source address, the timestamp, the OAuth client identifier, the endpoint path, the HTTP method and the response code. For the SCIM endpoint and the OAuth2 API, these fields answer the questions that matter during an incident: which client called, from where, what it touched and whether GLPI accepted it. Leave out request bodies, user attribute payloads and bearer tokens. A SCIM provisioning request carries personal data about every employee it creates or changes, and a token in a log line is a credential sitting in a second place. Confirm with your GLPI version which fields the web server access log and GLPI's own logs record by default, and whether the proxy in front of GLPI rewrites the source address, because a logged address that is always the proxy makes the allowlist review meaningless.

Set retention and access before the first log is written. Decide how long access records are kept based on your own policy and any regulatory duty you carry, then restrict read access to the people who review them, usually the security operations team and the GLPI administrators, not every reader of the server. Forward the records to the central log platform you already run so that failed authentications and denied requests from the GLPI endpoints are visible alongside identity provider events. Build one alert for repeated 401 or 403 responses from a single client and one for any successful call from a source address outside the allowlist. Treat these as review triggers rather than automatic blocks, and confirm with your monitoring team how alerts are routed.

Failed logins and denied requests are usually the first signal that an integration is misconfigured, not that it is under attack. After an allowlist change, a proxy migration or a new identity provider tenant, watch for a client whose successful request count drops to zero while its 401 or 403 count rises. Keep a baseline of normal calls per client so the drop is obvious. GLPI upgrades can also change endpoint paths, authentication behavior and response codes, so repeat this check after every upgrade, and before you close the change, confirm that the SCIM and API calls from each integration still appear in the logs with the expected client identifier. If a path disappears from the logs, verify whether the endpoint moved or the integration stopped calling it.

Limits to confirm in your environment before you publish

Each item below is a question to answer with GLPI's documentation, the identity provider's vendor, or your own testing before anything is exposed. None of them is a finding of this page. Together they decide whether the SCIM and API endpoints can be published narrowly enough for your risk model.

SCIM core or plugin, and its support status

Confirm whether the SCIM capability in your GLPI version ships in the core or comes from a plugin, and who supports it. A plugin adds its own release cycle, its own upgrade steps and its own security patches, so the version you test must be the version you run. Ask the vendor or plugin maintainer which GLPI versions it supports and how long it will receive fixes. Record the answer in your upgrade plan.

OAuth2 grant types the provider requires

Check whether the OAuth2 API in your GLPI version supports the client credentials flow or the authorization code flow your identity provider or integration expects. The grant type decides whether a scoped, non-user client is possible at all, and it changes which scopes and redirect settings you must configure. Test the exact token request your provider sends against a staging instance before you commit to a design.

Stable source address ranges from providers

Ask each cloud identity provider whether it publishes source address ranges for its provisioning traffic, and how often those ranges change. An IP allowlist is only as good as the list behind it. If ranges are not published or change without notice, an allowlist can block legitimate provisioning or leave gaps, and you will need another control, such as a dedicated reverse proxy rule with a documented review cycle.

Path and source filtering at your proxy scale

Confirm that your reverse proxy or load balancer can match on URL path and client source address together, and that it keeps doing so at the request volume your provisioning cycles generate. Test rule evaluation order, behavior behind another proxy that passes client addresses in headers, and what happens when a rule fails closed. Trusting forwarded address headers from untrusted hops is a common way to defeat source filtering.

Step-up authentication coverage for integration actions

Check whether your GLPI version's step-up authentication applies to the administrative actions your integration performs, such as creating users, changing profiles or altering authentication settings. If a provisioning token can trigger a sensitive change without re-authentication, the scoped client becomes the weakest point in the design. Test each action your integration needs in a non-production instance and document which ones require an interactive administrator.

Log retention under your policy

Confirm that your logging platform can retain proxy access logs and GLPI application logs for the period your policy requires, and that those logs include the source address, path, client identifier and outcome of each request. Check whether logs can be shipped off the GLPI host, how they are protected from modification, and whether your team can query them quickly during an incident involving a provisioning token.

Questions teams ask before exposing GLPI endpoints

How long does it take to expose GLPI SCIM and API endpoints safely?

The duration depends on how many integrations need access, how complex the reverse proxy and network path are, and how much vendor coordination the identity provider or integration partner requires. A single identity provider pushing users to a SCIM endpoint on a flat network is a short piece of work. Several cloud providers, OAuth clients with different scopes, a multi-site proxy and a change window with each integration owner take longer. The written scope should list each endpoint, each client, each source network and each test you expect to run, because those items set the schedule more than the GLPI version does.

What does an engagement cost, and what does the quote cover?

DeployOpen does not publish prices. Most engagements are fixed-scope, so the quote follows from a written scope that names the endpoints, integrations, proxy changes, logging requirements, verification steps and handover material. The one-time work covers design, configuration, testing and documentation. Ongoing review after a GLPI upgrade, periodic checks of client scopes and log reviews can be arranged as an optional retainer. When you request a quote, ask which items are one-time, which recur, what the client must provide, and what happens if an integration changes during the work.

Can our internal team expose GLPI endpoints without a partner?

Yes, if the team can verify which endpoints exist for its GLPI version, configure the reverse proxy rules, create scoped OAuth clients and review the logs. The skills that matter most are web server administration, a working knowledge of OAuth2 and SCIM provisioning, and the discipline to test denied requests as well as allowed ones. Teams that lack one of these usually fail at the logging step or leave a broad client in place after testing. Check the GLPI integration documentation for your exact version before you start, and confirm the SCIM behavior with the identity provider vendor rather than assuming it.

What do we need to provide before the work starts?

Four things make the work predictable. Name an integration owner for each identity provider or integration, who can confirm the expected requests and approve test changes. Provide proxy access, or a change process that lets the implementation team edit the reverse proxy configuration in a non-production environment first. Provide administrator access to the identity provider so provisioning tests can run end to end. Agree a test window with the business, because provisioning tests create, change and disable real GLPI accounts. Missing any of these usually extends the timeline more than the technical work itself.

Are IP restrictions alone enough to protect GLPI APIs?

No. IP restrictions limit where requests can come from, but they do not limit what an allowed caller can do or prove who made a request. A compromised cloud integration, a shared egress address or a forgotten test client can still read or change data. Combine source restrictions with OAuth clients scoped to the minimum needed, short token lifetimes where the platform supports them, and access logs that record client, path, method and result. Review the allowed networks whenever an identity provider changes its outbound ranges, and confirm those ranges with the vendor.

How do we check and log GLPI endpoint access?

Logging should answer three questions for every request: which client made it, what it called, and whether it was allowed. Configure the reverse proxy to write these fields to a central store, and keep GLPI's own event logs for changes made through the API. Test with a request from an unlisted network, an out-of-scope token and an expired token, and confirm each one appears in the logs with the expected result. Retention and alert thresholds should follow your own policy and any regulation that applies to you, so confirm those requirements before the logging design is final.

What should we do after a GLPI upgrade?

Treat the upgrade as a reason to re-verify the exposed surface. Check the release notes for changes to endpoints, OAuth behavior and authentication, then confirm that the SCIM and API paths your proxy allows still exist and behave as expected. Back up the database, files and the config directory, including the key files, before the update. Reapply proxy rules that were managed outside GLPI, rerun the denied-request tests and review the OAuth clients for unused scopes. The GLPI update documentation describes the backup and update steps, and it should be followed in the order it gives.

Does exposing these endpoints require a compliance review?

It often does, because provisioning and API access affect who can see and change asset and user records. The review should confirm the access model, the logs that show who used the endpoints, and the process for removing clients when an integration ends. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies make the assessment itself. Ask your assessor early which evidence they expect for access to these endpoints, so the logging and client records are designed to produce it.

How DeployOpen scopes and delivers a restricted GLPI endpoint

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including GLPI. For SCIM and API exposure, the work starts with a written list of which identity providers and integrations need which endpoints, then builds the access controls, client scopes and logging around that list.

How we scope

Inventory every identity provider, SCIM consumer and API integration that will reach GLPI, with its source addresses and required actions.
Agree the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope.
Confirm which GLPI version and web server layout you run, because the endpoint controls differ between deployments and must be checked in your environment.

How we build

Configure the web server or reverse proxy to limit the SCIM and API paths to approved source ranges and HTTP methods.
Create one OAuth2 client per integration with the narrowest scopes it needs, and document each client's owner and purpose.
Enable and forward access logs for the exposed paths to your central logging platform, and test that failed and blocked requests are recorded.

How we hand over

Deliver the configuration, client register, allowlist rationale and test results as documentation your team can review and maintain.
Walk through the runbook for adding an identity provider, rotating a client secret and revoking an OAuth2 client.
Record which controls are evidence for your own assessors, while noting that DeployOpen prepares evidence but does not issue audit reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Re-check the exposed endpoints after each GLPI upgrade, since plugin and API behavior can change between releases.
Review the allowlist and OAuth2 client list with your team on a schedule you agree, so stale entries are removed.