Single sign-on

Part ofSet up Soveryne for your organisation

Everyone signs in to Soveryne with the work account they already have. Soveryne does not create passwords. This page explains which identity providers are supported, what your identity-provider administrator needs to check, who is let in, and how people get their role.

Supported identity providers

Identity provider	Notes
Google Workspace	Recommended when you have a choice. Google always confirms that an email address is verified.
Microsoft Entra ID	Work and school accounts. Personal Microsoft accounts are not accepted.
Okta	Available when Soveryne has set up Okta for your organisation. Ask your Soveryne contact.
GitHub	The person needs a verified primary email address on their GitHub account.

Single sign-on uses OpenID Connect (OAuth 2.0). Another OpenID Connect provider can be added by Soveryne on request. SAML is not supported.

What your identity-provider administrator needs to do

In the standard set-up you do not register an application in your identity provider. Soveryne signs people in through its own sign-in application, so adding a product, a person or a web address later needs no change on your side.

Your identity-provider administrator only needs to confirm three things:

Every person has a verified email address, and your provider shares it at sign-in. Soveryne admits people by their verified email address only. User names and other attributes are not trusted.

People may sign in to a third-party application.

Microsoft Entra ID: check your user-consent settings. If your tenant requires administrator consent for applications, an administrator approves the Soveryne sign-in application once.

Google Workspace: check that third-party app access allows the Soveryne sign-in application.

Everyone signs in with an address on one of your organisation's email domains, or has been invited personally (see below).

Note

If your organisation must use its own OAuth application, Soveryne can configure a workspace to use it. You then register a confidential web application with your provider and give Soveryne its client details. Soveryne gives you the redirect address to register. People on such a workspace sign in on the product's own web address.

Who is let in

A person can sign in when their verified email address is either:

on one of the workspace's allowed email domains, for example everyone at example.com, or

invited personally by exact address, for example a consultant at another company.

Some rules apply:

Public email services such as gmail.com or outlook.com can never be an allowed domain. You can still invite one exact address at such a service.

A workspace with no allowed domain and no invitations lets nobody in. Command will not switch a provider on until you add at least one of them.

People who have been deactivated cannot sign in, even when their domain is allowed.

A refused sign-in does not create an account.

You manage allowed domains and invitations in Command under Departments › Single sign-on. You can also set them up during the set-up wizard (see Command).

How people get their role

People receive their access automatically when they sign in. Command checks these rules in order and uses the first one that matches:

Order	Rule	Example
1	Invited people: an exact email address gets a role	`j.devries@example.com` → Policy editor
2	Claim → role: a group or role your identity provider sends gets a role	`security-team` → Incident responder
3	Domain → role: everyone on an email domain gets a role	`example.com` → Auditor
4	Provider → role: everyone who signs in through a provider gets a role	Google → Auditor

A person whom no rule matches can sign in but sees nothing until someone gives them a role.

Administrator access is never granted through single sign-on. Your first administrator is set up by Soveryne or by your partner when your workspace is created.

A claim → role rule needs the name of the claim to read, entered under Role claim key. Point it only at a group or role claim that your identity provider controls, never at a value people can edit themselves.

To change one person's role, use Users & roles. The change stays in place at their next sign-in.

See Roles and permissions for what each role can do.

Signing in for the first time

There are two ways in:

The Soveryne sign-in page. After you sign in, it lists the applications you can use, under Your applications. Choose one to open it, already signed in.

The product's own web address. Choose your identity provider on the Soveryne sign-in page.

Your account is created the first time you sign in. If you later sign in with a different provider that confirms the same email address, you reach the same account.

People appear in Users & roles in Command after their first sign-in. Until then, invitations are listed under Pending invites.

Troubleshooting

What you see	Likely cause	What to do
You return to the sign-in page without a message	Your email domain is not allowed and you were not invited; your provider did not confirm your email address; or your account was deactivated	Ask your administrator to add your domain or invite you. Check that your identity provider shares a verified email address.
You are signed in, but every page is empty	No rule gives you a role yet	Ask your administrator to invite you with a role, or to add a Domain → role rule for your domain
Your provider's button is missing	The provider is not switched on for this workspace	Ask your administrator to switch it on under Single sign-on. If it is not listed there, contact Soveryne.
A personal Gmail or Outlook address is refused	Public email services cannot be allowed as a domain	Ask your administrator to invite that exact address
GitHub sign-in is refused	Your GitHub account has no verified primary email address, or it is private	Verify a primary email address in your GitHub settings
Colleagues on a subsidiary's domain are refused	Only the listed domains are allowed	Add the domain under Allowed email domains
Saving Single sign-on fails with "An SSO mapping may not assign the admin role."	A rule tries to grant administrator access	Remove that rule. Administrator access is assigned separately.

← PreviousOnboarding checklist Next →Roles and permissions