Authentication and SSO
Last updated
Was this helpful?
Last updated
Was this helpful?
To use SSO with Entra from GLPI, you can follow this Access to the Microsoft 365 Tenant is required. You will also need to download the Oauth SSO plugin available on the marketplace.
To use SSO with OKTA from GLPI, you can follow this You will need admin access to OKTA. You will also need to download the Oauth SSO plugin available on the marketplace.
To use SSO with Google from GLPI, you can follow this You will need admin access to your Google Tenant. You will also need to download the OAuth SSO plugin available on the marketplace
To use SSO with Keycloak from GLPI, you can follow this You will need admin access to Keycloak. You will also need to download the Oauth SSO plugin available on the marketplace.
There are several possible reasons for this problem:
the secret has expired,
the password for the account obtaining SSO authorization has expired,
you have requested a URL change and the provider-side application has not been modified.
Yes, under certain conditions. It is possible in administration
> authentication
> Other authentication methods
to set the option remove the domain of logins like login@domain
to Yes
. This action carries a risk depending on how your SSO application is set up on the provider side.
!!! Danger If you allow SSO access to external tenants, it is possible that identity theft could occur. For example, I log on with john.doe@mondomaine.com. Generally speaking, you can't have 2 identicals logins on the same tenant. If you have a homonym in the company, the logins will be different. On the other hand, if a namesake from outside the tenant, such as john.doe@gmail.com, logs in, he or she will be able to impersonate you. This option should therefore be limited to SSO applications that use a single tenant.
Here is the list of providers currently available:
Yes. From your SSO application, click on setup
at the top of the screen. Then click on hide standard login form
. It will still be possible to connect with an internal account by clicking on standard login
.
To apply rules to an SSO connection, you need to choose one of the following criteria:
Authentication type is External Authentications
or
Email contains @mydomain.com
To check what's causing the problem, you can activate the debug mode, which will point you in the right direction. You can follow this to help with Setup
Amazon,
Microsoft Entra,
Facebook,
Github,
Gitlab,
Google,
Keycloak,
OKTA
This can happen when you use V2 of the Oauth SSO plugin. Setting up claims
and API permissions
is necessary for the plugin to work properly. You can follow this to set up your application.
This happens when the authorisation rules have not been set up. In fact, once authentication has been successfully completed, GLPI checks that you have an assigned authorisation. GLPI also checks that a rule has been set up to assign you one automatically. If this is not the case, access to GLPI will be denied. To set up these authorisation rules, please refer to this to help you configure them.
This can happen if your OAuth SSO authentication source is also the provisioning source. If the option Fetch information from user profile
(available from Setup
> Oauth SSO applications
) is set to No
, Oauth SSO will not retrieve information from user records. If you wish to retrieve user information, change this option to Yes
and make sure that the fields in Setup
> Authentifcation
> Other authentication methods
and the claims of your OAuth SSO application are filled in (more information ).
If, on the other hand, you have an external provisioning source such as SCIM, and the Fetch information from user profile
option is set to Yes
, OAuth SSO will overwrite the current information and replace it with the information entered in Setup
> Authentication
> Other authentication methods
. We therefore recommend that you set this option to No
if you have an external provider (more information ).
No, SSO is only a means of connection and does not provision users upstream. To do this, you need to use the