Working proof · built on a live instance · August 30, 2026

GLPI 11 Multi-Customer Isolation, Demonstrated

A fresh GLPI 11 instance stood up today, upgraded in place to the current 11.0.8, configured to the RRCG scope of work: the Root / RRCG / Customers entity tree, least privilege self service profiles, tickets raised through the new GLPI 11 portal, and the release blocking customer isolation test executed and passing, including the direct URL bypass attempt.

Prepared by Yinka Aderibigbe.

01The entity structure from your scope, live

Root entity
├── RRCG                        (internal)
└── 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

GLPI admin ticket list showing two tickets, each labeled with its full entity path under Root entity, Customers, Customer A and Customer B — The technician view: one ticket per customer, each carried by its entity path. Entity = security boundary, exactly as the scope requires; groups and locations stay what they are and are never used as isolation substitutes.

02Tickets created through the GLPI 11 portal

GLPI 11 self service portal home for the Customer A user — Each test user raised their own ticket through the new GLPI 11 self service portal (Form Render based service catalog), signed in with entity scoped Self-Service authorization.

03The release blocking test passing

Your scope names cross customer exposure a release blocking failure and lists the exact checks. Executed with dedicated test identities:

Customer A user ticket list showing only the Customer A ticket — **Customer A view.** alice.customer-a lists tickets with an unfiltered all statuses query and sees exactly one row: her own. The Customer B ticket does not exist for her, title included.

Access denied message shown when Customer A user opens the Customer B ticket by direct URL — **Direct URL bypass attempt.** The same user requests the Customer B ticket by its literal id (/front/ticket.form.php?id=2). GLPI refuses at the permission layer, not the navigation layer. This is your check number five.

Customer B user ticket list showing only the Customer B ticket — **Customer B view.** The mirror image: bob.customer-b sees only the Customer B ticket.

04Edition and plugin dependencies, identified up front

Your posting asks candidates to flag anything needing GLPI Network, a paid plugin, a workaround, or scope adjustment before implementation. Verified against current GLPI project documentation:

Requirement	How it is delivered	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 2FA fallback	Native GLPI 11 (relevant only to break glass accounts)	native
Entra ID SSO (OIDC) with MFA	OAuth SSO plugin, Entra supported, UPN or OID or email matching; MFA enforced on the Entra side	GLPI Network
Entra SSO without GLPI Network	Community single sign on plugin exists; GLPI 11 compatibility must be validated on your instance before committing	validate first
Entra group sync / SCIM provisioning	SCIM based provisioning is part of the paid stack; not assumed available. Fallback: rule based profile and entity assignment on first SSO login plus documented JML procedure	validate first
Exchange Online OAuth mail collector	oauthimap plugin (free, Teclib, marketplace) for helpdesk mailbox with modern auth; no Basic Authentication anywhere	free plugin
GLPI Agent inventory	Native server side; agent deployment standard defined per scope section 8.5	native
RustDesk / Hudu / n8n / Zabbix / Acronis	Links, IDs and selective API per your modular architecture; GLPI side API identities with least privilege	API based

No unsupported workaround is proposed anywhere. The two validate first rows are the honest edges: they get confirmed on your instance in week one, before any dependent work, so the paid or community decision is made with evidence rather than assumption.

05Method

Official GLPI 11 release archives (built on 11.0.4, upgraded in place to 11.0.8 with php bin/console db:update; isolation tests re run and passing on 11.0.8), MariaDB 10.11, PHP 8.3, CLI database install, entity tree and scoped authorizations configured, test tickets raised through the portal by each customer identity, isolation verified in the interface and by direct object reference. The same discipline your UAT section demands, applied before the first conversation.

This page accompanies my proposal for the RRCG GLPI 11 engagement. Screenshots are unedited captures from the live instance built for this proof. Plugin and edition facts verified against GLPI project documentation and release announcements, August 2026.