Single Sign-On (or SSO) allows you to manage your organization’s entire membership via a third-party provider.
GitGuardian supports the SAML2 standard for SSO which allows the Owner or any Manager, of the workspace to configure any SAML2-enabled Identity Provider (IdP) system (Google, Okta,...).
The following detailed IdP procedures are available:
Below is the generic procedure you can follow for all other SAML2-enabled IdP:
In order to integrate GitGuardian with your Identity Provider, you must first register GitGuardian (Service Provider) as an application on the IdP’s side. Follow these steps carefully:
- Navigate to Settings > Authentication
- Click on "Configure"
- Fill in the SAML endpoint provided by GitGuardian (ACS url, SP Entity id)
- Fill in Email or EmailAddress as the primary identifier (Name ID format)
- Set RSA_SHA256 for the signature algorithm, and SHA256 for the digest algorithm.
Once GitGuardian is registered as an application on your IdP’s side, you need to provide your IdP metadata fields on GitGuardian (Service Provider side) in order to complete the integration:
- While still on the Authentication config page of your workspace settings, complete the form with:
- Entity Id [required]
- Single Sign On Url [required]
- Single Log Out Url [optional]
- X509 certificate [required]
- Submit the form to fully register the SAML integration.
The setup is complete. Your workspace will have a dedicated SSO login url for your collaborators to sign in using your IdP.
You can register this SSO login url on the IdP side to enable the SSO flow with one click directly in the IdP interface. However this IdP-Initiated flow carries a security risk and is therefore NOT recommended. Make sure you understand the risks before enabling IdP-initiated SSO.
GitGuardian supports Just-In-Time (JIT) provisioning. New members of your workspace are automatically registered with GitGuardian on their first login attempt with SAML2 SSO if they are authorized on the IdP side.
You don't need to invite users manually. You just need to authorize them on the IdP's side by being part of the "GitGuardian group". Users who are not part of the GitGuardian group on the IdP side will be rejected during their attempt to sign in via SSO.
GitGuardian does not support JIT deprovisioning yet.
Because GitGuardian uses Just-In-Time (JIT) provisioning, new members will be given a default role upon their first login.
"Member" is the default setting. You can modify this default in your Authentication settings page
Once you have successfully set up an SAML2 SSO integration, in your Authentication settings page, you have the option to force the SSO:
- If the option is turned ON, all the members of your workspace will have to go through your IdP in order to be able to access your GitGuardian workspace. Thus, only the users you have authorized on your IdP’s side will be able to sign into your GitGuardian workspace.
- If the option is turned OFF, members of your workspace can still login via SSO, going through your IdP, but they can also sign up via email. As a result, users that are not whitelisted on the IdP side can still login to your GitGuardian workspace.
In order to avoid being blocked out in case of an SSO malfunction, the force SSO feature does not apply to the Owner of the workspace. The Owner of the workspace will always be able to log in with email/password.
Once an SAML integration is completed, the users of your GitGuardian workspace (usually the Owner or a Manager) can request to reserve one or several specific email domains that belong to them or your company. This feature goes one step further in the authentication/security aspect. It is independent from the “force SSO” feature.
When you reserve a domain
company.com, you restrict users with an email address "firstname.lastname@example.org" from signing up to GitGuardian and creating their own workspace. For a company, it is a guarantee that there will only be one workspace for users having an email address “email@example.com”.
When a user tries to sign up with a reserved email domain address, he is alerted that he is required to sign up via SSO.
Users who already have a workspace and are impacted by a newly reserved email domain will not be affected. They will be able to join the workspace that requested these domains be reserved for SSO.
Also, reserving an email domain will allow users to find your custom SSO page just by just filling in their email. Without this option you would need to bookmark your SSO login url.
This feature is reserved to workspaces with Business access (Business or Business trial plans). After then end of a Business trial, the email domains will no longer be reserved.