Single Sign-On (SSO)¶

A user's identity in Qbee is their email address. Authentication methods are decoupled from that identity. Password with TOTP, SAML single sign-on, and social login through Google, Microsoft, and GitHub are all ways to prove ownership of an email address. Whichever method a user authenticates with, the result is the same kind of user session, and the user is subject to the same role-based access control (RBAC) model: the same roles, the same permissions, the same resource-based access rules. See Users & Roles for that model.

Qbee offers two distinct sign-in mechanisms beyond a Qbee-managed password, and they work differently:

SAML single sign-on is configured per account by an account administrator. It connects one account to one SAML 2.0 compatible identity provider (IdP). This is the feature most people mean by "SSO."
Social login (Google, Microsoft, GitHub) is a platform-wide OAuth2 option. There is nothing to configure at the account level. Any user can link a Google, Microsoft, or GitHub account to their Qbee user and sign in with it.

The rest of this page covers both, starting with social login (available to everyone) and then SAML (an account-level, purchased capability).

How authentication interacts with user management¶

Authentication answers "is this person who they claim to be?" It does not answer "what are they allowed to do?" Two practical effects follow:

Roles come from Qbee, not the IdP. Qbee does not read roles, groups, or permissions from IdP data (SAML attribute statements, Microsoft app roles, GitHub team membership, or OAuth claims). An administrator assigns roles in Qbee when the user is created. See User provisioning below.
Post-login behavior is identical. Once signed in, a SAML user, a social-login user, and a password user are indistinguishable for every other purpose.

Authentication events (sign-ins, regardless of method) are not recorded in the Qbee audit log. See Audit Log for what the audit log does record.

Social login lets a user authenticate with an account they already have at Google, Microsoft, or GitHub. It requires no account-level setup and no plan upgrade. Qbee registers the OAuth applications centrally, so there is no client ID, client secret, or redirect URI for you to manage.

On the Qbee login page, below the email and password form, three buttons are available:

Sign in with Google
Sign in with Microsoft
Sign in with GitHub

The password form and the social buttons appear together, so users can choose either method on the same page.

To sign up or sign in, the user must already have an account with the chosen provider (a Google, Microsoft, or GitHub account). The provider verifies the user's identity and returns their email address to Qbee.

Linking and unlinking providers¶

A user manages their own social connections under Profile → OAuth2 Authentication:

The Active list shows the providers already linked to the user, each with an option to unlink.
The Available list shows providers not yet linked, each with a button to link it.

A user can link more than one provider at the same time. If a provider account is already tied to a different Qbee user, linking fails with "Another user is already registered with this OAuth2 provider."

Password authentication and social login coexist. Linking a social provider does not remove the user's ability to use a password, and a user with a password can still add social login.

SAML single sign-on¶

SAML connects one Qbee account to one SAML 2.0 compatible identity provider (IdP). It suits organizations that centralize user lifecycle management in an IdP, often for compliance reasons. Removing a person from the IdP does not change their Qbee user record; it only prevents them from completing a SAML sign-in, because the IdP will no longer authenticate them (see Deprovisioning and sessions).

Prerequisites¶

SAML SSO is a purchased capability. It is not self-service. To have it enabled for your account, contact support@qbee.io. Once purchased, the capability is switched on for your account.
The CompanyManage permission in Qbee, which is required to edit account settings (typically an account-administrator role). See Users & Roles.
Administrator access to your SAML-compatible IdP, with the ability to register a new application (service provider) and supply its metadata.

Values Qbee exposes to your identity provider¶

After SAML is enabled, the Single Sign On card on the Account page shows the values you enter into your IdP when registering Qbee as a service provider. Each is displayed as a copyable field. In the values below, {companyId} is your account identifier, filled in automatically by Qbee:

Field in Qbee	Value	Use in the IdP
Login URL	`https://<your-qbee-site>/sso/{companyId}`	The single sign-on / start URL.
ACS URL	`https://<your-qbee-site>/sso/{companyId}/acs`	The Assertion Consumer Service (reply) URL.
Audience Entity ID	`https://<your-qbee-site>/sso/{companyId}`	The audience / service-provider entity ID.

Qbee expects the IdP to send the user's email address as the SAML NameID. Only users whose email matches the account's trusted domains are allowed to sign in (see below).

Configuring SAML in Qbee¶

On the Account page, open the Single Sign On card and select Edit. The form has these fields:

Active: a checkbox that turns SAML sign-in on or off for the account.
SSO URL: the sign-in URL of your IdP.
Entity ID: the issuer or entity ID of your IdP.
IdP Certificate: the IdP's public X.509 signing certificate, in PEM format.
Trusted Domains: the email domains permitted to authenticate through this account's SAML.

Select Save to store the configuration.

Once a certificate is stored, the Single Sign On card displays its expiry date and SHA-256 fingerprint. Watch the expiry: an expired IdP certificate will cause SAML sign-in to fail.

SAML and other methods coexist¶

Enabling SAML does not disable password or social login for the account. Authentication methods are stored as a list, so an account can offer SAML to one group of users and password or social login to others at the same time. An account has a single SAML configuration; Qbee does not support connecting one account to multiple SAML identity providers.

User provisioning¶

User provisioning is manual and admin-driven for SAML. Qbee does not provide SCIM integration, so there is no automated directory sync, and Qbee does not auto-create users on a first SAML sign-in. A SAML user must already exist in Qbee before they can sign in; if no matching user exists, the SAML sign-in fails.

An administrator adds a user by entering their email address. One of two things happens:

If no user with that email exists anywhere in Qbee, a new user is created and linked to the account. The email is treated as verified, so no separate confirmation step is needed before the user can sign in.
If the user already exists in Qbee (for example, because another account invited them first), an account-user link is created. The user keeps the same identity and existing authentication methods.

Roles are assigned in Qbee at user-creation time by the administrator. Qbee does not map roles from IdP data.

Social login behaves slightly differently for brand-new signups: a user who signs up with Google, Microsoft, or GitHub and is not yet known to Qbee has a user and account created for them automatically at that moment. Within an existing account, administrators still add users by email as described above.

To revoke access, an administrator disables or deletes the user in Qbee's Users list. Disabling a user in Qbee ends their active sessions immediately (see below).

Per-user authentication policy¶

The account's authentication methods, set on the Account page, apply to every user on the account by default. An administrator can narrow that list for an individual user by overriding the policy from that user's Edit user dialog.

To open the dialog, go to the Users section (top-right menu), find the user, open the actions context menu (⋮), and select Edit. The dialog shows the user's email (which cannot be changed for an existing user), their roles, an Enabled checkbox, and an Override company authentication policy checkbox.

When the override checkbox is cleared, the user authenticates with whatever methods the account allows. When the checkbox is selected, a list of authentication methods appears, and the administrator chooses which methods this user is permitted to use:

Password
Password + Email
Password + TOTP
OAuth2 Google
OAuth2 Microsoft
OAuth2 GitHub
SAML2

The selected list replaces the account-level list for this user; it is not merged with it. Clearing the checkbox again returns the user to the account default.

A typical use is an account that offers both password and SAML2, where one group of users must sign in with SAML2 only. The account administrator leaves the account list unchanged and applies a SAML2-only override to each user in that group.

Deprovisioning and sessions¶

There are two levers, and they differ in timing:

Disable or delete the user in Qbee. This ends the user's active sessions immediately.
Disable the user at the IdP (SAML) or at the social provider. This prevents the user from obtaining a new Qbee session, because they can no longer authenticate. It does not, on its own, terminate a session the user already holds. Qbee does not re-check the IdP on every request. An existing session remains valid until its tokens expire (the short-lived auth token within minutes, the refresh token within seven days). This timing is the same for SAML and social login.

To cut off active access at once, disable or delete the user in Qbee in addition to (or instead of) deprovisioning at the IdP.

Benefits¶

One fewer password. Users authenticate against an IdP or social account they already use.
Centralized lifecycle management (SAML). Disabling a user at the IdP prevents future SAML sign-ins to Qbee. Combine it with disabling the user in Qbee to end active sessions immediately.
Reduced account-recovery overhead. Password resets and lockouts move to the IdP or social provider.
Per-account and per-user authentication policy. Because credentials are decoupled from account access, the set of allowed authentication methods can be set for the account and refined for individual users.
Trusted domains (SAML). Only users whose email is in the account's trusted-domain list can authenticate through the account's SAML connection.

What Next?¶

I want to...	Go to
Manage users, assign roles, or restrict access by resource	Users & Roles
See what else lives in the Account menu	Account settings
Link or unlink a social login provider on my profile	Profile
Check what the audit log records (and what it does not)	Audit Log