I've spent several days trying to connect GLPI to Keycloak using SAML 2.0, but I can't get the login flow working. Most of my other services are already using OIDC successfully, and LDAP and Active Directory integrations work too, so I'm not sure whether I'm misunderstanding SAML or running into a GLPI-specific issue. The current error from GLPI is "Invalid Requester."
Are there any simple, free SAML-compatible applications I could run in a virtual machine for practice and troubleshooting? I'd like to better understand the protocol and determine whether my Keycloak configuration or GLPI's SAML plugin is the problem.
4 Answers
Use a browser SAML inspection tool to capture the authentication exchange. It can show the redirect, entity ID, ACS URL, timestamps, certificates, and assertion details. That’s useful for confirming that the browser is being sent to the expected endpoints, although an “Invalid Requester” error may happen before GLPI even evaluates user attributes.
Before spending more time on SAML, check whether you actually need it. GLPI’s documentation generally recommends its OAuth/OIDC SSO plugin, and there are specific setup instructions for using it with Keycloak. The SAML plugin is mainly useful when SAML is required by your organization or identity provider.
If you want a separate environment for learning SAML, Shibboleth is a well-known, free implementation with broad protocol support. It’s powerful but not especially simple, so it may teach you a lot while also adding another layer of configuration. In this case, switching GLPI to its Keycloak-compatible OAuth/OIDC plugin is likely the quicker path unless SAML is mandatory.
For a basic SAML test, verify the entity ID on both sides, the ACS/reply URL, the signing certificate, and the allowed clock difference. Keycloak can be strict about timestamps, so temporarily increasing the clock-skew allowance can help isolate the problem. Also disable message encryption during initial testing unless it is required, since mismatched encryption certificates often create confusing errors.
I’d start with signing only and add encryption later. That keeps the first test focused on whether the assertion is being accepted at all.