Single sign-on

With single sign-on (SSO) your people sign in to Dialgem through the identity provider they already use (Okta, Microsoft Entra ID, Google Workspace, Auth0, OneLogin and others). Owners set it up under Settings, Single sign-on. It works over OpenID Connect or SAML 2.0.

Set up

1. Choose a protocol and enter your provider's details.
   • OpenID Connect: the issuer URL, a client ID and a client secret. Register the redirect URI shown on the page at your provider. Dialgem reads the provider's published configuration, checks that it names the same issuer you entered, and keeps your client secret encrypted.
   • SAML: the provider's entity ID, its sign-on URL and its signing certificate (PEM). Give your provider the entity ID and assertion consumer (ACS) URL shown on the page, or its metadata URL. Responses must be signed (SHA-256 or stronger) and carry the person's email in an email attribute or as the NameID. Assertions may be encrypted (see below).
2. Prove each email domain you own. Add example.com, then add the TXT record shown (_dialgem-verify.example.com with dialgem-verification=<token>) and press Check now. Only a proven domain is trusted, and only one organization can hold a given domain: this is what stops one organization from signing in as another's staff. Public mailbox providers such as gmail.com cannot be claimed.
3. Turn it on. It needs a saved provider and at least one verified domain.

People type their work email on the sign-in page under Sign in with SSO and are sent to your provider.

Who gets an account

The first time someone signs in, they join with the role you chose (member or admin; never owner). A person who already has a Dialgem account at that address is signed in to it and keeps the role they have. The provider's stable user id is remembered, so a changed email address there neither creates a second account nor takes over another. Dialgem staff accounts can never be signed in this way.

An address at a domain you have not verified is refused, whatever the provider says.

Requiring it

Require it for everyone turns away passwords and "Continue with Google/GitHub" for addresses at your verified domains, including password resets, and sends those people to your provider. Owners are exempt so that a provider outage or an expired certificate cannot lock you out of your own settings; they keep their password.

Several providers

An organization can use up to five providers, for example one per company it has joined or one per product line. Each has its own name, protocol, domains and on/off and "required" switches. A domain belongs to exactly one provider. People typing their work email under Sign in with SSO are sent to the provider that holds their domain.

Starting at the provider (IdP-initiated)

By default sign-in must begin at Dialgem: a SAML response the provider sends unprompted is refused, because it cannot be tied to a sign-in we began and so a stolen one could be replayed. If your provider can only start sign-in from an app tile, tick Allow sign-in that starts at the provider on that SAML provider. The response is still signed, audience- and recipient-checked, time limited and accepted once; only the "this answers our request" check is lost.

Encrypted assertions and signed requests

Under a SAML provider choose Make service provider certificate, then give your provider the updated metadata. It can then encrypt assertions to Dialgem (RSA-OAEP key transport with AES-GCM or AES-CBC; the older RSA 1.5 is refused). Responses must still be signed.

Some providers also insist that our requests are signed. Tick Sign our sign-in and logout requests and Dialgem signs its sign-in request, its logout request and its answer to your provider's logout request (HTTP-Redirect binding, RSA-SHA256, with the same key pair), and the metadata then says AuthnRequestsSigned="true" and publishes the certificate for signing. Upload the new metadata to your provider. Making a new certificate replaces the key, so the provider needs the new metadata again.

Single logout

• OpenID Connect. Signing out of Dialgem sends the browser on to the provider's end-session page when it publishes one. In the other direction, register the back-channel logout URI shown on the page; when the provider signs someone out it tells us and we end their sessions that began through it.
• SAML. Give the provider our single logout URL and enter its logout URL. Signing out of Dialgem sends a logout request; a logout request from the provider (redirect or POST binding) must be signed by the provider's certificate and ends the matching sessions.

Automatic provisioning (SCIM)

On a provider, Make a token and give your identity provider the SCIM base URL and the token (shown once; only a hash is kept). Dialgem supports SCIM 2.0 Users:

• Create adds the person to your organization with the provider's default role, if their email is at one of that provider's verified domains. An existing account is joined rather than duplicated. If that account's email was never confirmed, everything its registrant set up is cleared first (password, sessions, authenticator app, passkeys, recovery codes, and any Google, GitHub or other provider they had linked), so someone who registered your address in advance cannot keep a way in. The same rule applies when the person arrives through sign-in with Google or GitHub, and a passkey on an unconfirmed address cannot sign in at all.
• Update, deactivate and delete change the name or email, or remove the membership and end every session in your organization. The Dialgem account itself is never deleted (it may belong to other organizations), and an owner is never removed this way (the request is refused).
• Filtering by userName and externalId works.
• Groups are supported (create, read, filter by displayName, replace, patch members and name, delete). They do nothing on their own: see Roles below. Only people your provider created can be members.

SCIM actions are in the audit log as the token that made them.

Roles

A new person's role comes from, in order: the groups they are in that you have mapped, the role of their email domain, then the provider's default role. It is always member or admin, never owner.

• Per-domain role. On each verified domain choose Join as member, Join as admin or Provider default. It applies to people joining from then on (through sign-in or SCIM); people already in keep their role.
• Roles from groups. Under Roles from groups list the groups your provider pushes (matched ignoring case) and the role each grants. Someone in several mapped groups gets the highest. Saving a mapping applies it at once to everyone the provider manages and the page tells you how many roles changed.

What it does not do

• Two-step verification is not asked again at sign-in after SSO: your provider has authenticated the person, and its own second step applies. But an organization's "require two-step verification" policy is a separate rule that looks only at whether the person has a Dialgem authenticator app or passkey, so if you turn on both, SSO people must also set one up.
• Role mapping from claims in the sign-in token itself (only SCIM groups map to roles).
• SAML signatures made with SHA-1 are refused; reconfigure the provider to SHA-256.

Changes to providers, domains, tokens and enforcement are written to the audit log, and need a fresh second step from owners who have one.