Written proof · August 30, 2026
GLPI 11 multi customer isolation, demonstrated
A fresh GLPI 11 instance, upgraded in place to 11.0.8 and set up as a shared, multi customer helpdesk: one entity per customer, least privilege self service profiles, tickets raised through the GLPI 11 portal, and the customer isolation test passing, including the direct link bypass attempt.
The entity structure
Root entity
├── Internal (provider staff)
└── Customers
├── Customer A ← alice.customer-a, Self-Service, this entity only, non recursive
└── Customer B ← bob.customer-b, Self-Service, this entity only, non recursive
Each customer user holds the self service profile on their own entity only, with no recursion into any other entity.
Tickets raised through the GLPI 11 portal
The isolation test, passing
Cross customer exposure is the failure that must never ship, so it was tested with dedicated identities, one per customer.
alice.customer-a lists tickets across all statuses and sees exactly one row: her own. The Customer B ticket does not exist for her, title included.
/front/ticket.form.php?id=2. GLPI refuses at the permission layer, not the navigation layer.
bob.customer-b sees only the Customer B ticket.Edition and plugin dependencies, mapped before any build
Before any build I map what GLPI 11 covers natively and what needs GLPI Network, a paid plugin or a workaround. This map was checked against GLPI project documentation in August 2026.
| Requirement | How GLPI 11 covers it | Dependency |
|---|---|---|
| Webhooks | Native in GLPI 11, new in this major version | Native |
| Forms and self service portal | Native GLPI 11 form editor and portal | Native |
| Local two factor fallback | Native in GLPI 11, relevant only to break glass accounts | Native |
| Entra ID single sign on over OIDC, with MFA | OAuth SSO plugin with Entra support, matching on UPN, OID or email, with MFA enforced on the Entra side | GLPI Network |
| Entra single sign on without GLPI Network | A community single sign on plugin exists; its GLPI 11 compatibility is checked on the target instance before any work depends on it | Validate first |
| Entra group sync or SCIM provisioning | SCIM provisioning is part of the paid stack, so it is not assumed. Fallback: rule based profile and entity assignment at first sign on, plus a documented joiner, mover and leaver procedure | Validate first |
| Exchange Online mail collector with OAuth | The free oauthimap plugin from Teclib, in the marketplace, for a helpdesk mailbox with modern authentication and no Basic Authentication anywhere | Free plugin |
| GLPI Agent inventory | Native on the server side; the agent deployment standard is defined per environment | Native |
| Remote access, documentation, automation, monitoring and backup tools | Links, IDs and selective API calls, through GLPI side API identities with least privilege | API based |
No unsupported workaround appears anywhere in the map. The two rows marked validate first are checked on the target instance before any work depends on them, so the paid or community choice rests on evidence rather than assumption.
Method
I built the instance from the official GLPI 11 release archives on 11.0.4 and upgraded it in place to 11.0.8 with php bin/console db:update, then ran the isolation tests again, which passed on 11.0.8. The stack is MariaDB 10.11 and PHP 8.3 with a command line database install. I configured the entity tree and the scoped authorizations, had each customer identity raise its test ticket through the portal, and verified isolation both in the interface and by direct object reference.
Screenshots are unedited captures from the live instance built for this proof on August 30, 2026. Plugin and edition facts were checked against GLPI project documentation and release announcements in August 2026.
Start here
Start with one real finding.
Send me your company domain, and I will send back one specific problem with its evidence, free.
Or write to admin@maikaza.com