Single sign-on and sign-in connections

Single sign-on lets everyone in your workspace sign in with Google, GitHub or Microsoft instead of a password. This article is for workspace owners and admins who want to control how members sign in, which email domains are trusted, and whether sign-in through your identity provider becomes the only way in.

#Overview

• A sign-in connection is your workspace's policy for one provider (Google, GitHub or Microsoft) — which email domains it accepts and what happens when someone new signs in with it.
• You can require everyone to use single sign-on, limit connections to your own email domains, and mark outside contractors as external so they're not blocked.
• Nothing here changes anyone's role or permissions, and every change is recorded in your Audit Log.

#Add a sign-in connection

1. Go to Settings → Sign-in.
2. Under Sign-in connections, choose a provider to add.
3. The connection is on straight away — anyone in your workspace can now use that provider.

NoteIf a provider isn't offered, it hasn't been set up for the platform yet — ask your InfraNest administrator.

#Limit sign-in to your own email domains

By default a connection accepts any address. To narrow it:

1. Open the connection's settings.
2. Type the domains you want to allow into Allowed email domains, one per line — or switch on Use our verified domains so the connection automatically follows the domains you've already verified.
3. Check the row, which always shows what the restriction currently accepts.

Two things to know:

• Subdomains are not included. Allowing acme.com does not allow mail.acme.com. Add it separately if you need it.
• Turning on "Use our verified domains" before you've verified any accepts everything. The row says so when that happens.

Members who can't use any of your connections are protected: if a restriction would lock somebody out while single sign-on is required, InfraNest refuses to save it and names the people affected.

#Require single sign-on

Switching on Require single sign-on means your workspace only opens for people who signed in through one of its connections. An owner can also get in with a passkey, as the emergency way in. Other members' passkeys do not count, so removing someone in your identity provider really does end their access.

1. Before turning it on, register a passkey for at least one owner, under My account → Sign-in & security.
2. Go to Settings → Sign-in.
3. Review the list under the switch — it shows exactly what will get people in: each connection that's switched on, owners' passkeys, and external members.
4. Turn on Require single sign-on.

It applies to your workspace, not to the whole account of everyone in it. Somebody who also belongs to another workspace can still sign in with a password to reach that one. When they then open yours, InfraNest asks them to sign in with your single sign-on, and they stay signed in to both. Until they do, they see nothing of yours: your notifications are left out of their bell, and your workspace shows in their workspace list by name only, with a key beside it. Someone who belongs only to workspaces that require single sign-on cannot use a password at all.

For those people, their My account → Sign-in & security page says which provider signs them in, and does not offer a password, two-step verification or passkeys: none of them would get them into your workspace. InfraNest also refuses creating them some other way, such as through a password-reset email, and does not link a Google or GitHub account your workspace does not accept. Owners keep their passkeys, because that is the emergency way in. People who also belong to another workspace keep everything, with a line explaining that it is for their other workspaces.

Because no password opens your workspace any more, your password rules stop applying while single sign-on is required: minimum length, required symbols and maximum password age. They are shown greyed out, so they no longer shape passwords your members keep for their other workspaces. They are kept as you set them and apply again if you turn the requirement off. Require two-factor authentication stays on: members who sign in through your own identity provider already meet it with that provider's own two-factor check, but it still applies to an owner signing in with a passkey and to Google, GitHub or Microsoft sign-ins.

Before you can enable it, InfraNest checks that nobody gets stranded:

• every member must be able to use one of your connections, and
• at least one owner must have a passkey registered.

WarningLocked out anyway — the passkey owner has left, or the device is gone? Contact InfraNest support. An administrator can restore password sign-in for you. It's recorded in your audit log and your owners are notified, so you'll always see that it happened.

#Add people from outside your workspace

An MSP's engineer, an auditor or a contractor is usually not in your identity provider, so your single sign-on could never let them in.

1. Go to Settings → Members.
2. Open the ⋯ menu on their row.
3. Choose Mark as external.

An external member signs in the way their own company requires, and your workspace lets them in however they did. It is recorded in your Audit Log. An owner can never be external.

#Turn a connection off

1. Go to Settings → Sign-in.
2. Use the switch on the connection to stop people signing in with it, or choose Remove to delete it entirely.

If single sign-on is required and it's your only connection, InfraNest refuses — turn off the requirement first.

TipThe switch is almost always what you want. Turning a connection off stops sign-ins straight away, keeps everyone's accounts linked to it, and can be switched back on. Removing a connection also unlinks everyone who signs in through it, and someone who has only ever signed in this way has no password to fall back on. Once anybody is signing in through a connection, InfraNest stops you from deleting it and greys out the delete button — turn it off instead.

#Good to know

• Signing in with a provider never changes anybody's role or permissions.
• Every change here is written to your Audit Log.
• While single sign-on is required, only owners' passkeys get in. That's deliberate: it is the emergency way in, and a member who leaves your company must not keep one that bypasses your identity provider.
• Turning on the requirement also ends sessions that were started some other way before it: people are asked to sign in through your provider the next time they open the workspace.