Single sign-on, with your identity provider in charge.

Expand

Choose your identity provider

Every provider below works. The steps differ, and so does one detail that matters later: whether your provider publishes a metadata URL we can keep reading, or only a file you send us once.

Set it up

1. 1

   Choose your provider

   An owner or admin opens Organisation settings, Single sign-on, and picks the provider. The page shows the values to paste into your provider, with copy buttons.
2. 2

   Connect

   Give us your provider's metadata: its URL, or the XML file. Add your email domains (public mail domains cannot be used) and create the connection.
3. 3

   Verify and activate

   Add a DNS TXT record to prove you own each domain. Once a domain shows as verified, link your existing members and activate single sign-on.

Until a domain is verified, nobody is sent to your provider. Activating makes single sign-on available; enforcing it is a separate, later choice.

Available is not the same as enforced

Turn on Require SSO for everyone, or require it person by person from the Members page.

The owner break-glass

Organisation owners are always exempt from enforcement. An owner keeps a password and can always sign in with it and a two-factor code. Identity providers fail: certificates expire, metadata gets edited, administrators leave. The owner exemption is the way back in.

Certificates

Your provider signs every sign-in with a certificate that expires, usually three to ten years out. When it expires, single sign-on stops working, and with enforcement on, everyone except owners is locked out until it is renewed. Expired certificates are the most common cause of single sign-on outages, because nobody remembers a date years away. So we do.

What we do about it

• We read your provider's certificate every day and record when it expires.
• We email your owners and admins 60, 30, 14, 7, 3 and 1 days before it expires, and daily once it has.
• The expiry date shows in your single sign-on settings at all times.
• If you gave us an XML file rather than a metadata URL, we start warning at 90 days, because renewing will need you to send us the new file.

Why a metadata URL is worth having

With a metadata URL we re-read your provider's details by ourselves, so when it rotates its certificate we pick up the new one and your people never notice.

What happens on a downgrade

When your organisation moves to a plan without single sign-on:

• Enforcement is switched off.
• Members are unlinked, your verified domains are removed, and the connection is disabled.
• Your owners and admins get an email saying so.
• Your people reset their password once to get back in, because enforcement had removed it. A normal “forgot password” from the sign-in page is all it takes.

Nothing else is deleted. If you move back to a plan with single sign-on, you can set it up again; you will verify your domains again.

If something goes wrong

• Nobody can sign in and the certificate has expired. Renew it in your provider, then make sure we have the new metadata. An owner can still sign in with their password and two-factor code to make the change.
• Someone is not sent to your provider. Check their email domain is one of your verified domains: matching is on the domain, not the address.
• You cannot switch enforcement on. No owner has both a password and two-factor authentication yet. Set those up on an owner account first.

Still stuck? Reply to any email from us, or write to support@stablebaseline.io.