You are using an unsupported browser. Please update your browser to the latest version on or before July 31, 2020.
close
You are viewing the article in preview mode. It is not live at the moment.
Home > Glider Administration > Using SSO with GliderBIM
Using SSO with GliderBIM
print icon

Instead of having a separate username and password, your users can use your corporate identity provider to log in to GliderBIM instead. As an administrator, this gives you a number of advantages:

  1. Users only have one username and password to remember
  2. Your IT department is responsible for passwords and 2FA resets
  3. You can enforce 2FA methods not supported by GliderBIM, such as biometrics or using a specific device
  4. When a user leaves the organisation, access is revoked automatically
  5. You can ensure that a user’s workstation complies with your security policies before allowing access using tools such as Intune, Jamf and Carbon Black

GliderBIM implements SSO using the SAML 2.0 protocol, which is a very common authentication standard implemented by identity providers such as Entra (formerly AzureAD), Okta, Duo and others.

At Glider, we are passionate about a secure internet for everyone, so we do not charge for the use of SSO like some of our competitors.

How it works

SSO is enabled on a per-domain basis, such as for the domain mycompany.com. All users with an email address ending in mycompany.com will use your given identity provider.

There are two ways for this to work:

  1. Service Provider (SP) initiated workflow: a user enters their email address in the login screen and they are redirected to your identity provider
  2. Identity Provider initiated workflow: a user clicks on the gliderbim button in your company identity provider portal. Most, but not all identity providers provide a portal showing all applications that a user has.

In both cases, your identity provider will sign a request describing who is logging in. This request will be given to the user’s browser temporarily and they will pass it through to gliderbim. Our system will check the signature against the certificate provided at setup. If this matches and the request is valid, the user will be authenticated and will be able to begin accessing GliderBIM.

The user must be able to access your identity provider and GliderBIM at the same time, but the identity provider could be accessed via a VPN via split tunnel for example. The trust relationship is established via cryptographically signed requests and does not require the two systems to be able to communicate.

JIT Provisioning

By default, if a user signs in via SSO but does not exist, an error message is presented to the user. However, with our provisioning profiles feature we can define a default set of project and group memberships for the user instead. This greatly improves the speed of onboarding new staff. When accessing GliderBIM for the first time, the user is automatically created and authenticated in a single action.

To use provisioning profiles, your identity provider must pass the Name attribute with the SAML assertion. This will provide the initial name for the user when they are created, although they can change it later.

GliderBIM also supports multiple provisioning profiles, which can be specified by sending the ProvisioningProfile attribute. On your Identity Provider side you can use user group membership or other factors to describe the user’s default profile and ensure that a document controller does not get the same rights as a security cleared architect for example.

Once the user is created, they can be modified and the provisioning profile does not affect the user further. Administrators can then add them to projects and other groups as appropriate. Changing the provisioning profile configuration does not affect created users retroactively.

Migration pathway to SSO

Migrating to using SSO involves a few administration steps:

  1. Set up a SSO profile on your system, or ask your administrator to do so
  2. Contact our support team with information about the SSO profile's metadata
  3. Test that the SSO profile is working as expected
  4. Notify your users about the SSO profile requirement
  5. Contact our support team to go live and enforce the use of SSO for all sessions

Please see our documentation on setting up SSO for more information.

Migration pathway away from SSO

If you decide to not use SSO with GliderBIM after setting it up, you can request for our support team to disable SSO. We can do this very easily with a small configuration change.

Users will not have passwords at this point, so will be unable to log in. However, they will be able to use the ‘forgot password’ feature to set a new password.

Identity Provider Hinting

If you have an internal intranet site or custom application that links users to GliderBIM resources, clicking on any GliderBIM link will send unauthenticated users to the gliderbim login screen. The user will need to enter their email address at this point, and they will need to log in.

If you know ahead of time which SSO domain a user will use, you can add a x-sso-domain parameter to the end of the URL. If the user is not authenticated, they will be redirected to the given identity provider.

For example, this URL will redirect all unauthenticated users to the identity provider for mycompany.com: https://app.gliderbim.com/project/210-king/documents?x-sso-domain=mycompany.com

If the user does not use GliderBIM frequently, this can improve the user experience, and when combined with automatic provisioning, this can grant the user access to a given resource even if they were not GliderBIM users before clicking on the link.

This feature is provided to improve the user experience, but using it is not mandatory.

Important notes

While SSO gives you a number of benefits, you should be aware of some drawbacks also when deciding to use SSO:

  1. If your provider is unavailable then users cannot login to gliderbim. By enabling SSO, you are also taking on responsibility for the uptime of the identity provider service.
  2. You are responsible for ensuring that the identity provider is secure, because gliderbim will trust every assertion signed by your identity provider. By enabling SSO, you are also taking on responsibility for securing the identity provider service and ensuring only valid users have access.
  3. If users are unable to log in to their SSO account, we cannot help, as this is outside our control. By enabling SSO, you are also taking on responsibility for resolving user access problems.

However, despite these points, we feel the benefits of enabling SSO outweigh these slight drawbacks.

Next Steps

Please follow the instructions on Setting up SSO for GliderBIM, or contact our support team or your account manager for more information.

Feedback
0 out of 0 found this helpful

scroll to top icon