Single Sign-On (SSO)

Enterprise Single Sign-On lets your team sign in to Resilic with your own identity provider (IdP) — Microsoft Entra ID, Okta, ADFS, PingFederate, and others — instead of a separate Resilic password. Sign-ins are routed by your email domain: once SSO is active, Resilic recognises addresses on your verified domain and offers sign-in through your identity provider. Anyone without a Resilic password is sent straight there; anyone who still has one gets the choice between the two (see After activation).

You set this up yourself under Settings → Single Sign-On. Only an Owner or Admin sees this section.

Before you start

• You need administrative access to your identity provider (to add a new application / relying party, to read its metadata, and — for OIDC — to create a client and read its client ID and secret).
• You need to be able to add a DNS TXT record for your company domain (or ask whoever manages your DNS to add one).
• Decide which of your IdP groups should get which Resilic role (see Who on your team gets access below). Your IdP will need to send group information in the sign-in token for automatic access to work.

Step 1 — Verify your domain

Routing sign-ins by email domain is powerful, so Resilic first makes you prove you control the domain — otherwise someone could redirect another company’s logins. Enter your company domain and Resilic gives you a DNS TXT record to publish:

_resilic-sso.your-domain.example   →   <verification token>

Add it at your DNS provider, then click Verify domain. DNS changes can take a few minutes to propagate; if verification doesn’t succeed immediately, wait and try again.

Verified domains only — and subdomains count separately

You can verify several domains; each one needs its own DNS TXT proof. Your team signs in with addresses on one of the verified domains — all of them lead to the same identity provider.

Subdomains are separate domains. Verifying acme.example does not cover mail.acme.example — verify it additionally if you need it.

What matters is how this fails: anyone using an address on an unverified domain gets no error — they get the ordinary password sign-in. From the outside that is indistinguishable from SSO never having been set up. So if particular colleagues “can’t get in via SSO”, check which domain their address is on first.

Removing a domain stops sign-ins through it immediately. The last verified domain of an active SSO connection cannot be removed — disable SSO first.

Step 2 — Connect your identity provider

Once the domain is verified, connect your IdP:

1. Choose the protocol (SAML or OIDC) and how you’ll supply the metadata — a metadata URL or pasted XML.
2. For OIDC, also enter the client ID and secret you registered for Resilic at your identity provider. (SAML needs none — it trusts via the exchanged metadata and certificates.)
3. Save. Resilic sets up the connection and shows you the Service-Provider details — the entity ID, the ACS (reply) URL, and an SP metadata URL.
4. Register those details in your identity provider so it trusts Resilic, and make sure it sends the user’s group memberships in the sign-in token — that’s what drives automatic role assignment.

Resilic never stores your IdP’s certificates or secrets — the connection lives in the underlying identity layer, and Resilic keeps only the references it needs.

Step 3 — Test, then activate

1. Run a real test sign-in through your IdP: in a private browser window, open your organisation’s sign-in page, enter an email address on your verified domain, and complete the sign-in at your identity provider.
2. Back in Resilic, click Test sign-in — Resilic verifies that the identity layer actually observed a sign-in through your IdP (clicking without the real round-trip is rejected).
3. Once the verified test passes, click Activate SSO. From then on, sign-ins on your verified domain are routed to your identity provider.

You can Disable SSO at any time to fall back to password sign-in. Re-activating later asks you to run a fresh test first, so a broken IdP change can’t silently lock your team out.

Who on your team gets access

Signing in with SSO proves who someone is — it does not by itself grant access to your Resilic workspace. Access is decided when they first sign in:

• In a mapped group → added automatically. If the person is in an identity-provider group you’ve mapped to a Resilic role, they’re added to your workspace at that role the first time they sign in — no approval needed. You manage which group maps to which role (Owner, Admin, Member, …) and to which products; your IdP admin controls who’s in each group. This is the point of SSO: you govern access by group policy, not one person at a time.
• Not in a mapped group → request to join. Anyone who signs in but isn’t in a mapped group gets no access yet — they land on a “request access” screen, and an Owner or Admin approves them from Team & roles. Access is never granted silently.
• Already a member → the same account, automatically. Anyone who already belongs to the organisation and is merely arriving through your identity provider for the first time lands in their existing account: Resilic recognises the verified email address. Membership and role are untouched; no second account is created, and no extra step is needed.

If someone is later removed from all their mapped groups at your IdP, their Resilic access is suspended on their next sign-in — so off-boarding at your IdP flows through automatically.

Roles and per-product scope are always managed in Team & roles; SSO decides how people authenticate and which role they arrive with, not what a role can do.

Group mapping is set up with us during onboarding. Because every identity provider names and sends groups differently (Entra ID groups, SAML memberOf, and so on), the mapping from your IdP’s groups to Resilic roles is configured together with our team when you turn SSO on. Tell us which groups should get which role.

Your organisation’s sign-in page

Your organisation has its own sign-in address:

https://your-slug.app.resilic.ai

The slug is derived from your company name; the exact address is shown in the Single Sign-On settings, and invitation and welcome emails link straight to it. This page belongs to your organisation alone — which is why it can name your identity provider, something a shared sign-in page could not do without exposing every customer’s SSO domains.

Anyone who opens the general Resilic sign-in instead enters their email address once and is sent on from there.

After activation: password or SSO

Team members whose Resilic account existed before SSO was activated keep their old password. Activation alone does not move them onto SSO. That matters for off-boarding: someone disabled at your IdP could still sign in with the stale password. Accounts created through your IdP never have a password, so this only concerns pre-existing accounts.

On your organisation’s sign-in page, what’s offered is decided once the email address is entered:

The account has …	The sign-in page shows …
SSO only (no password)	a direct redirect to your identity provider
a password and SSO	the password field and a button to sign in with SSO
a password only	the password prompt only

Once SSO is active, the Single Sign-On settings show which members can still sign in with a password, and Enforce SSO-only sign-in removes those passwords — making your identity provider the only way in for them.

Break-glass: your own password is kept unless you explicitly opt in to removing it. Without a password, nobody can sign in — or deactivate SSO — if your identity provider is misconfigured or down. Keep one Owner password until a second Owner exists or you have verified your IdP setup is stable.

One account per organisation

Each organisation has its own sign-in area — and one account per person there. When an existing member first signs in through your identity provider, that sign-in continues into the existing account (recognised by the verified email address); from then on both routes work — password and SSO alike — for as long as the account keeps a password.

Anyone working for several companies — in consulting, say, or across a group — can use the same email address in each of those organisations; the accounts themselves stay separate per organisation. That is deliberate rather than a detour: each organisation fully controls its own sign-in area, and no account carries access from one organisation into another — not even if another organisation’s identity provider were compromised. To switch, you sign in at the respective organisation’s sign-in area; the app redirects you there.

Roles always apply per organisation: being an Owner in one does not make you more than a Member in another.