Other external authentication methods

The integration of GLPI and authentication sources beyond internal, LDAP, and IMAP is configured from the Setup > Authentication > Other authentication methods menu.

Central Authentication Service (CAS)

The configuration of a CAS server is comprised on the address of the server and its port (default 443). A base directory can be specified if needed. The return web address parameter allows you to redirect the user to a specific page after they log out from GLPI.

Once the CAS authentication is activated, each authentication is automatically redirected to the CAS server. In order to log into an internal account or one authenticated through a different method, you have to add ?noAUTO=1 to the login URL.

The php-curl or php-dom extensions are required to be enabled for CAS authentication to function.

x509 certificate

The Email attribute for x509 authentication tells GLPI to look at the value of this attribute in the SSL\_CLIENT\_S\_DN HTTP request variable passed by the authentication system.

It is possible to restrict the accepted values for the O, OR, and CN fields of the client certificate. In order to specify multiple values for each field, you may separate each value with the $ symbol.

Other automatic authentications

GLPI can rely on other external systems to authenticate users such as:

• Basic Apache authentication

• Windows domain authentication

• Authentication coming from an authentication server like LemonLDAP::NG, Shibboleth, etc

When the user wishes to reach GLPI, this one checks the presence of a variable in the HTTP headers storing the login/username. If the variable is present, the authentication is allowed to be done. We can map the data transmitted by the authentication system with the fields of the user account of GLPI (name, first name, email, language...). To finish, the controls of authorizations are carried out. An option allows to remove the domain of the user's login (Ex: [email protected] > testuser).

The list of possible names for the headers is configurable, although the most common ones are already provided by GLPI. See Configuring headings.

SSO authentication in GLPI via a web server

In a Single Sign-On (SSO) architecture via the web server, it is not GLPI that performs the identity verification, but the upstream web server.

Example: if you use Windows authentication (Kerberos/NTLM) with Apache and the mod_auth_gssapi module, Apache communicates directly with the Active Directory domain controller.

Once the user is authenticated (for example, ‘John Smith’), Apache transmits this information to GLPI via HTTP headers. GLPI then simply retrieves the user ID without managing the authentication itself.

Authentication variables used by GLPI

GLPI can retrieve the user ID from different variables, depending on the web server configuration, the type of SSO, or the proxy used. Here are the main ones:1.

1. HTTP_AUTH_USER

• Origin: Standard HTTP authentication (Basic).

• Description: Variant of PHP_AUTH_USER. This variable is often generated by web servers configured in CGI mode or by certain third-party modules that directly inject the identifier into the HTTP headers.

2. REMOTE_USER

Origin: Industry standard (Apache, IIS, Nginx).

Description: This is the most widely used and secure variable for SSO. It is populated by the web server after successful authentication (Kerberos, NTLM, or LDAP).

Recommendation: For integrated Windows authentication, almost always use REMOTE_USER.

3. PHP_AUTH_USER

Origin: "Basic" authentication natively handled by PHP.

Description: Contains the username when the browser displays a standard login window. PHP automatically decodes the Authorization header sent by the browser to populate this variable.

4. USERNAME

Origin: System environment (often Windows/IIS).

Description: This variable comes directly from the system environment. Less common in modern web SSO, it can be used if PHP runs in a context where the system user session is passed to the PHP process.

5. REDIRECT_REMOTE_USER

Origin: Apache server with mod_rewrite.

Description: Technical fallback variable. During an internal redirect via .htaccess, Apache sometimes prefixes REMOTE_USER with REDIRECT_.

Use case: If authentication works on the homepage but not on some subpages, use this variable.

6. HTTP_REMOTE_USER

Origin: Reverse proxy or Load Balancer (Nginx, F5, Citrix, etc.).

Description: Used when the front-end equipment performs authentication instead of GLPI and transmits the login via an HTTP header.

Note: The HTTP_ prefix indicates that the value is transmitted over the network; it is therefore less secure than a local system variable.