When GLPI SAML single sign-on with the SAMLSSO plugin is the right route
Choose the SAMLSSO route when your identity policy makes SAML mandatory and your GLPI instance must sign users in through that identity provider. This is the case the community SAMLSSO plugin for GLPI 11 covers. The older GLPI SAML plugin for GLPI 10 is deprecated, so a new project should not start from it. Teclib recommends OAuth SSO and SCIM unless SAML is mandatory, which makes the protocol requirement the deciding factor rather than a preference for federation in general. Before you commit, confirm in writing with your identity team that SAML is a hard requirement for this GLPI instance, not a default setting carried over from other applications.
The plugin supports multiple identity providers, which matters if your organization has more than one directory, for example after an acquisition or where contractors authenticate through a separate tenant. Each provider can be offered as a button on the login page, or users can be routed to the right provider by their email domain. Those two login patterns change how users experience sign-in and how you plan support, so decide them early. Map each identity provider to the users and entities it serves, and check which attributes each one sends for account matching and profile assignment.
Confirm three things before scoping the work: that your GLPI version is 11, because the plugin targets that release line; that the identity provider's SAML configuration can meet the plugin's settings; and who supports the plugin when something breaks. The plugin is community-developed with support from its developer, so it is not covered by Teclib's support. Ask your implementation partner and your own team to agree that ownership on paper, including who tracks plugin updates across GLPI 11 and 12 upgrades.
What you need in place before configuring SAML in GLPI
SAML sign-in only works when the GLPI platform, its web address and the identity provider are ready before the plugin is touched. Each item below is a prerequisite that is cheap to check now and expensive to discover halfway through a SAMLSSO configuration.
Target GLPI 11 release
Plan the SAMLSSO setup against GLPI 11, since the community SAMLSSO plugin is the maintained route for that line while the GLPI SAML plugin for GLPI 10 is deprecated. If you are still on GLPI 10, the upgrade must come first, and the old SAML plugin must be removed completely before the new one is installed. Confirm the exact GLPI 11 patch level you will run against the plugin documentation before you lock the version.
PHP and database versions
The GLPI 11 installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and state that only MySQL and MariaDB are supported. Check these against the server you plan to use, not the version on your workstation. The README on the main branch lists newer minimums (PHP 8.3 or later, MariaDB 10.11 or later), so plan for the higher of the two if you intend to track later GLPI releases.
Document root and URL rewriting
The web server document root must point to GLPI's public directory, not the installation root, with URL rewriting that routes requests through index.php. This applies to Apache, Nginx, lighttpd or IIS. SAML callbacks land on GLPI routes, so a misconfigured root exposes application files and breaks the login flow in ways that look like plugin faults. Test a plain GLPI login from the public address before adding SAML.
Stable HTTPS public URL
The SAML assertion consumer and logout endpoints are built from the URL users type into the browser, so the GLPI address must be fixed, reachable by users and identity providers, and served over HTTPS. Decide the hostname before configuring any identity provider, because changing it later means updating every relying-party registration. Confirm that any reverse proxy passes the original host and protocol headers to GLPI.
Identity provider metadata and certificate
Collect the identity provider metadata, the signing certificate and its expiry date, and the attribute names used for the login and profile mapping. Ask the identity team who owns the signing key and how it rotates, since an expired certificate locks every user out at once. Agree the entity ID and the callback URL in writing with the identity provider administrator before the first test sign-in.
Tested non-SSO administrator account
Keep a local GLPI administrator account that does not depend on SAML, and confirm its password and recovery path before enabling SSO. If the identity provider is unreachable or a mapping rule is wrong, this account is the only way back into the platform without direct database access. Test it by signing in, then document who holds it and where the credentials are stored.
How to configure the SAMLSSO plugin step by step
This sequence takes a GLPI 11 instance from a verified backup to a tested SAML sign-in flow, with each identity provider registered, mapped and checked before users depend on it. Confirm the exact menu paths and screens against the plugin documentation for the version you install, because plugin releases change the configuration pages.
Back up the database, files and config directory
Before changing anything, the administrator takes a full backup of the GLPI database, the application files and the config directory, including the glpi.key and glpicrypt.key files. These keys protect stored secrets and encrypted fields, so a restore without them can leave data unreadable. Store the backup somewhere separate from the server and test that the archive can be opened. The step is complete when a restore has been rehearsed on a non-production copy or the backup has been verified by checksum and file listing.
Confirm GLPI 11 and retire the old SAML plugin
The SAMLSSO plugin targets GLPI 11, and the older GLPI SAML plugin is deprecated for GLPI 10. If the instance still runs GLPI 10 or has the old plugin installed, the administrator updates to GLPI 11 first, then removes the old plugin completely so that no leftover files or settings conflict with the new one. Plugins are suspended after a new version is detected, so each plugin must be reactivated after the update. The step is complete when the GLPI version page shows version 11, and the plugin list no longer shows the old SAML plugin.
Install and activate the SAMLSSO plugin
The administrator places the SAMLSSO plugin in the GLPI plugins directory using the release that matches the GLPI 11 version in use, then installs and activates it from the plugin administration screen. Check that the plugin is community-developed and that the developer's support channel is known before relying on it for production sign-in. The step is complete when the plugin shows as installed and active, and the GLPI log shows no errors on the next page load.
Register GLPI as a service provider
In each identity provider, the administrator creates a SAML application for GLPI. The entity ID, the assertion consumer service URL and the single logout endpoint must match the public URL that users type in their browser, including the scheme and any path prefix. Any mismatch produces signature or audience errors that are hard to diagnose later. The step is complete when the identity provider lists the GLPI application and the expected endpoints are shown in its configuration with no pending errors.
Import or enter the identity provider metadata
The administrator imports the identity provider metadata file or pastes the metadata URL into the SAMLSSO configuration. Where metadata cannot be imported, the signing certificate, the single sign-on URL and the entity ID are entered manually, and the certificate must be checked for expiry. Map the name identifier and the user attributes that GLPI needs, such as login, email and group membership, to the fields the plugin expects. The step is complete when the plugin reads the metadata without error and displays the identity provider name and certificate details.
Configure each identity provider
For every identity provider, the administrator sets its display name, its login strategy and any default profile or entity assignment that should apply to new users. When more than one identity provider is used, each one needs its own entry and its own test user, so that a failure in one does not hide problems in another. Confirm the plugin's documentation for how it creates or updates users on first sign-in before enabling it for everyone. The step is complete when each provider appears as a separate entry with the intended settings saved.
Choose button-based login or domain-based redirection
The administrator selects how users reach each identity provider. Button-based login shows a sign-in option on the GLPI login page for each provider and suits organizations where users pick their provider. Domain-based redirection sends users straight to the right provider when they enter an email address with a known domain, which suits organizations with one identity provider per domain. The choice should be tested with a user from each domain before rollout. The step is complete when the login page shows the expected buttons or a test email address redirects to the correct provider.
Test sign-in, sign-out and fallback access
The administrator signs in with a test account for each identity provider, checks that the correct GLPI profile and entity are assigned, then signs out and confirms that the session ends. A local administrator account should remain available and be tested separately so that an identity provider outage does not lock out all administrators. Review the GLPI logs for SAML errors. The step is complete when every test account signs in and out as expected, the fallback account works, and no authentication errors appear in the logs.
Migrating from the deprecated GLPI SAML plugin
Migrating from the deprecated GLPI SAML plugin requires two steps in a fixed order: update the instance to GLPI 11 first, then remove the old GLPI SAML plugin completely before installing and configuring SAMLSSO. The plugin documentation states this sequence directly, so the old plugin should not be left disabled in the plugin directory while the new one is set up. Plan the order as a change window with a rollback point: a verified backup of the database, the files and the config directory, including glpi.key and glpicrypt.key, taken before any version change. The GLPI update procedure requires this backup in any case, and those two key files are needed to read encrypted data after a restore.
The update step has a known side effect. Since GLPI 11.0, plugins are suspended once a new version is detected, and they must be reactivated after major updates. Expect the SAMLSSO plugin and every other plugin on the instance to appear inactive after the update, and check each one for compatibility with GLPI 11 before reactivating it. Once SAMLSSO is installed, record every identity provider definition, login button label, domain-based redirection rule and group or profile mapping from the old configuration, because reconfiguration is manual work. Confirm with the plugin developer or the plugin documentation which settings carry over and which must be recreated, and do not assume the old SAML metadata or certificates will be reused without checking them against each identity provider.
Re-test after the change, not just at go-live. Verify each identity provider separately, including a login with a user who exists only in that provider, a login with an account that should be refused, and the forced or optional SSO behavior you chose. Confirm that the correct GLPI profile and entity are assigned, that logout and session expiry behave as expected, and that the local fallback administrator account can still sign in if an identity provider is unavailable. Also test the flows that depend on SSO, such as the API and any integrations that rely on the same user accounts. Keep the old SAML configuration and backup until this testing is signed off.
Choosing button login or domain-based redirection
With button-based login, the sign-in page shows one entry for each configured identity provider. A user selects the provider that employs them, is sent to that provider, and returns to GLPI with a SAML assertion. The user's email address does not decide the route, so the choice is explicit and visible on the page.
- Who it suits: Organizations with a small number of identity providers, or users who may belong to more than one tenant and must pick the right one.
- Support load: Users need to know which button to press, so a short instruction in onboarding material prevents wrong-provider attempts.
- Login page layout: Confirm how your plugin version labels and orders the provider buttons, because the page is the only place users see the choice. The SAMLSSO plugin documentation is the next read for configuration details.
- External accounts: A button lets a partner or contractor pick their own provider without a domain mapping.
- Local login visibility: Confirm whether the standard GLPI login form stays on the page beside the buttons in your build.
Before go-live, sign in with a test user from each identity provider and confirm the correct button reaches the correct tenant and that the account lands in the expected entity and profile.
With domain-based redirection, GLPI reads the domain of the email address a user enters and redirects that user to the identity provider mapped to the domain. Users with a single corporate address see no provider selection at all, which removes a step for most staff. The design depends on every domain having exactly one owner.
- Experience: Fewer steps for most users, but an address with an unmapped domain gets no redirect and needs another route in.
- Domain ownership: Each domain should map to exactly one provider. Overlapping or forgotten domains cause wrong redirects or failed logins.
- Subsidiaries and aliases: Plan for secondary domains, acquired companies and alias addresses, since they will not match a primary mapping unless you add them.
- Identifier matching: The login identifier must match what the provider returns, so confirm the username and email attributes on both sides before mapping domains.
- Outage behavior: Decide what users experience when a provider is unreachable, because a redirect-only path leaves them stuck unless a local route remains available.
Before go-live, test with addresses from every mapped domain, plus one unmapped address, and confirm the unmapped case lands on the page you intend.
Both modes can coexist with local GLPI accounts. Local and break-glass accounts are the route in when an identity provider or its signing certificate fails, so the choice between buttons and redirection affects how easily an administrator reaches that route during an incident.
- Break-glass accounts: Keep at least one local administrator that is tested outside the SSO path, with credentials held under your own control.
- Button mode: The standard login form may remain visible beside the provider buttons, which keeps the fallback obvious. Confirm this in your build.
- Redirect mode: A redirect can hide the local form for mapped domains, so administrators may need a direct route or an address outside the mapped domains to sign in locally.
- Recovery drills: Test the fallback after each change to provider settings, mappings or certificates.
- Certificate tracking: Record signing certificate expiry dates for every provider, because both modes fail together when one certificate lapses.
Before go-live, confirm which login form appears for a mapped domain and whether the break-glass account still works with redirection enabled.
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. SAML works as an external method, so the mode you choose changes what a user sees before that order runs. Confirm the exact sequence on your version in a staging instance.
- Identity collisions: A local account with the same login as a federated user may be matched first. Decide early whether identities are unique across sources.
- Redirect timing: A domain redirect sends the browser to the provider before any local check, so confirm whether a local password can still be entered for that address.
- Button timing: The user's button choice selects the provider path, so local matching depends on how the plugin hands off the login. Verify this in testing.
- Duplicate accounts: Test a user who exists both locally and through SAML to see which record is used and whether the profile changes.
- Test matrix: For each mode, test a break-glass administrator, a federated user, an unmapped user and a user who also exists in an LDAP directory.
Document the order you observe, and get it signed off before enabling either mode for production users.
How SAML attributes map to GLPI users and profiles
This table pairs each identity provider attribute that a SAMLSSO login depends on with the GLPI user field or profile decision it feeds. Read each row as a item to confirm in the plugin settings and in the identity provider's claim configuration before go-live. The main takeaway is that profile and entity assignment rules must be designed and tested before users sign in, because a wrong group claim can grant the wrong access on first login.
| Attribute or decision | What it feeds in GLPI | What to confirm before go-live |
|---|---|---|
| Username (NameID or chosen claim) | Login name that must match the GLPI user record | Which claim the plugin reads as the username, and whether it is stable and unique in the identity provider |
| Email address | User email used for notifications and for matching existing accounts | The exact claim name and whether the identity provider sends it on every login |
| Given and family name | First and last name shown on tickets and asset assignments | Whether these claims are sent, and how the plugin maps them to GLPI fields |
| Group membership claim | Input to profile and entity assignment rules | Claim format (group names or IDs), whether the identity provider includes groups by default, and the size limit for group claims |
| Profile assignment rule | Sets the GLPI profile (for example, technician or administrator) on first and later logins | Written mapping from each group to one profile, with a fallback for users who match no group |
| Entity assignment rule | Places users in the correct GLPI entity, which controls what data they can see | How multi-entity mapping is expressed, and who approves changes to the mapping |
| Existing local accounts | Accounts created before SAML may conflict with SSO-created users | Whether the plugin links to existing accounts by username or email, and a cleanup plan for duplicates |
| Login strategy and identity provider selection | Decides which identity provider or button a user sees when several are configured | Whether button-based login or domain-based redirection fits your user population, and how users reach the local login fallback |
Security settings to decide before go-live
SAML moves trust for every GLPI sign-in to your identity provider, so the settings that protect that trust need decisions before users are switched over. The cards below cover assertion signing, certificate lifecycle, local break-glass access, session visibility and the encryption keys GLPI relies on. Each item is something to confirm in your own environment and in the plugin's configuration screens, not a default to accept.
Assertion signing and encryption
Decide whether GLPI will require signed SAML responses or assertions, and whether your identity provider will encrypt assertions to GLPI. Confirm which parts of the response are signed in your identity provider's configuration, because a signature on the wrong element can leave the login trust path weaker than it looks. Test with a deliberately altered response in staging to confirm that GLPI rejects it. Record the decision and the test result in your change record.
Certificate rotation and expiry tracking
The identity provider signing certificate and any GLPI-side keys have end dates, and an expired certificate stops all SAML logins at once. Record each certificate's expiry in your asset or calendar system, assign an owner, and agree on a rotation window before the expiry date. Confirm with the plugin documentation how a new certificate is loaded and whether both old and new certificates can be trusted during the switch. Rehearse the change in staging before production.
Local login for administrators
Keep at least one local GLPI administrator account that can sign in without the identity provider, so a broken SAML configuration does not lock out every administrator. Confirm how the SAMLSSO plugin's login strategies interact with the internal database login, and test that the local account still works after you enable SAML. Store its credentials in a controlled vault, restrict who can use it, and log each use. Document the procedure for using it during an outage.
Session handling and session review
Decide how long GLPI sessions should last and how quickly a disabled user loses access, since SAML sign-in alone does not end an existing session. GLPI 12.0.0 adds a view of active user sessions with the ability to revoke them, which can help administrators respond to a departed user or a suspected compromise. If your team runs GLPI 11 instead, plan a manual check of session behavior and a documented revocation step. Test a disabled account in the identity provider and confirm when GLPI stops honoring it.
Protecting glpi.key and glpicrypt.key
GLPI stores its encryption keys in the glpi.key and glpicrypt.key files, and protecting them matters because encrypted data depends on them. Limit file system permissions so only the web server and administrators who need them can read the files, keep them out of web-accessible paths, and include them in your backups under the same protection as the database. Losing these keys can make encrypted values unreadable after a restore, so confirm the restore procedure with a test. Review access to backup copies as well as the live files.
Common SAML failures in GLPI and how to fix them
This table lists the failures teams most often meet when wiring SAMLSSO into GLPI 11, with the likely cause and the fix for each. Work through the rows in order when a login fails, because the first rows (URLs, time and certificates) account for most broken callbacks. Keep a local administrator account working before you force SSO.
| Failure | Likely cause | Fix |
|---|---|---|
| Assertion rejected with an audience or destination error | Entity ID or ACS URL in GLPI does not match the values registered with the identity provider, including scheme, host and path | Copy the exact entity ID and assertion consumer service URL from the plugin configuration into the identity provider, and confirm both match the public URL users type |
| Callback loops back to the login page | Document root points at the installation root, or URL rewriting does not route the SAML endpoints through index.php | Point the web server document root at GLPI's public directory and confirm rewrite rules on Apache, Nginx, lighttpd or IIS before testing again |
| Assertion appears expired or not yet valid | Clock skew between GLPI's server and the identity provider, often on a VM without time sync | Synchronize GLPI's host with a trusted time source and confirm the identity provider and GLPI use the same clock |
| Signature validation fails | Expired or rotated signing certificate, or the wrong certificate uploaded to GLPI | Compare the certificate fingerprint and expiry date with the identity provider metadata, then upload the current certificate and track its renewal date |
| Login succeeds but the user is not created | Automatic user creation is off, or the NameID or username attribute is not present in the assertion | Enable user creation in the plugin, then check the attribute mapping against a test assertion captured from the identity provider |
| User created but has no useful rights | No rule maps the SAML claim (such as a group) to a GLPI profile and entity | Write authorization rules that map the group or attribute to a profile and entity, then test with a user from each group |
| Email or name fields are blank | Required attribute claims such as mail or displayName are not released by the identity provider | Ask the identity provider administrator to release the claims to the GLPI application and confirm the values in a test sign-in |
| Administrators locked out after SSO is forced | SSO enforced without a tested fallback, or the identity provider is unreachable during a change | Keep a break-glass local administrator, test a full sign-in and sign-out before enforcing, and document who can disable enforcement in the database |
Questions teams ask before configuring SAML in GLPI
What drives the cost of configuring SAML single sign-on in GLPI?
The cost follows the number of identity providers, how many login paths you need, and how much of your IdP and GLPI configuration already exists. The SAMLSSO plugin is community-developed, so the plugin itself carries no vendor license fee in the supplied facts, but you still pay for the people who plan, configure, test and document the work. Ask any quote to separate the GLPI upgrade to 11, the plugin setup, IdP configuration, testing against real users and handover. Ongoing costs are mainly your own staff time for plugin updates and IdP certificate renewals. Ask for each component as a line item so you can compare it with an internal build.
How long does a SAML integration with GLPI usually take?
Duration depends mostly on the identity provider and how many GLPI environments need the same setup. A single provider with clean attribute mapping and a test instance is a much shorter job than several providers with domain-based redirection, group-to-profile rules and a production cutover. No duration figure is supplied for this work, so ask any partner or your own team for a timeline built from a written scope. Also plan for the GLPI 11 upgrade if you are still on GLPI 10, since migrating from the GLPI SAML plugin requires that upgrade first.
What must our team provide before the SAML work starts?
You need administrative access to the identity provider, a way to create or update a SAML application there, and the IdP metadata or the values needed to build it. You also need access to the GLPI server, its web server configuration and a non-production instance for testing. Confirm who owns the signing certificate, how it renews, and which user attributes the IdP sends, such as the username and email. Finally, agree which groups or claims map to GLPI profiles, because those decisions are hard to reverse once users sign in.
Can an internal team configure SAML in GLPI without outside help?
Yes, if the team already runs GLPI and has someone comfortable with SAML concepts, certificates and web server configuration. The work is well bounded: install the plugin on GLPI 11, configure each identity provider, test login paths and migrate users safely. The risk sits in the details, such as mismatched entity IDs, certificate expiry, attribute mapping errors and locking out administrators. Plan a test instance, keep a local administrator account for recovery, and document each IdP setting. Outside help makes most sense when the team lacks identity expertise or needs the work delivered under a written scope.
What support does the community SAMLSSO plugin offer?
The SAMLSSO plugin for GLPI 11 is actively maintained as a community project with support from its developer, according to the supplied facts. That is different from a vendor support contract with response commitments. No SLA is stated, so do not assume one. Before you rely on it, check the plugin's release notes against your GLPI version, test each upgrade in staging and confirm who in your organization or partner will handle a broken login during an outage. Teams that need guaranteed response times should look at a support agreement with a provider that offers one.
When does OAuth SSO or SCIM make more sense than SAML?
Teclib recommends OAuth SSO and SCIM unless SAML is mandatory, according to the supplied facts. Choose SAML when a policy, regulator or existing IdP standard requires it, or when your identity provider only offers SAML for the application. If you are free to choose, OAuth SSO and SCIM can simplify provisioning and deprovisioning. GLPI Network subscriptions include some OAuth-related plugins, so review the subscription terms before choosing that route. Compare both options against your identity provider's supported features and your audit requirements before the design is fixed.
What breaks most often after SAML goes live in GLPI?
The most common problems are expired IdP signing certificates, changed entity IDs or callback URLs, and attribute claims that stop matching GLPI user records. Users can also be created with the wrong profile when group rules change. Another frequent gap is forgetting that GLPI plugins are suspended after a new version is detected and must be reactivated after major updates, which can disable SAML login until someone notices. Add certificate expiry to your monitoring, document the metadata URLs and test login after every GLPI or plugin update.
Who supports the SAMLSSO plugin and what that means for your team
The first thing to settle is who answers when SAML breaks. The SAMLSSO plugin is community-developed and supported by its developer, not by Teclib's core support. Teclib's own guidance for GLPI single sign-on is to use OAuth SSO and SCIM unless SAML is mandatory, so a SAML choice should be driven by a hard requirement from your identity or compliance team, such as a standing policy that only SAML assertions may be accepted. If that requirement does not exist, the support model alone is a reason to pick the OAuth route instead. Confirm the requirement in writing before the build starts.
The operational consequences follow from that split. Plugin releases are tied to GLPI releases, so each GLPI minor or major upgrade needs a check that the plugin version supports the target version before you change the application files. Confirm with the developer which GLPI versions the current release is tested against, and plan the upgrade sequence with the plugin in view. Under GLPI 11, plugins are suspended after a new version is detected and must be reactivated after major updates, so SSO sign-in can fail during an upgrade window if nobody has rehearsed it. Ask the developer about response times, how they publish security fixes, and whether they will review your IdP configuration.
Someone inside your organization must own the integration. That owner tracks plugin and GLPI release notes, holds the identity provider metadata and certificate renewal dates, decides when to roll a fix into production, and keeps a tested fallback login path for administrators. Name that role and a backup before go-live, and record who has authority to disable SAML and fall back to another method. Where your team lacks SAML depth, a fixed-scope engagement can cover configuration, testing and handover, but the internal owner still has to exist after the project closes.
How DeployOpen scopes and delivers GLPI SAML SSO
DeployOpen plans GLPI SAML single sign-on as a written, fixed-scope workstream inside infrastructure you control. The work covers the identity provider relationship, the SAMLSSO plugin on GLPI 11, the login strategies you choose, and the documentation your operations team needs after handover.
How we scope
- We record which identity providers, login strategies and GLPI entities the written scope covers before any work starts.
- We confirm the GLPI version, the migration path from the deprecated GLPI SAML plugin and the plugin removal steps.
- We agree in writing how public and private GLPI URLs, certificates and attribute mapping are handled for your environment.
How we build
- We configure the SAMLSSO plugin against your identity provider metadata, signing certificates and assertion attributes in a non-production instance first.
- We set up button-based login or domain-based redirection according to the scope, and test each identity provider you configure.
- We verify session behavior, fallback local login for administrators and the handling of users who are not yet provisioned in GLPI.
How we hand over
- We deliver a configuration record listing identity providers, endpoints, certificate expiry dates and the attributes GLPI expects.
- We document the runbook for certificate renewal, identity provider changes and plugin updates after each GLPI upgrade.
- We walk your team through test results and the rollback steps so they can run and change the setup without us.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Ask your plugin developer or the SAMLSSO project which support terms apply, since the plugin is community-developed.
- Confirm with your identity provider vendor which SAML features and certificate policies your tenant supports before scoping.
