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

As soon as a domain is verified, Resilic shows the service-provider details your identity provider needs — before you save anything. The order matters, especially for OIDC: your IdP issues a client ID and secret only for an application that already knows Resilic’s redirect URI.

1. Register Resilic at your identity provider with the values shown in step 2:

   • OIDC — the redirect URI. In Microsoft Entra ID: App registrations → New registration → Authentication → Add a platform → Web → Redirect URI. Then create a client secret under Certificates & secrets, and under Token configuration add the optional claim email and the groups claim.
   • SAML — the SP entity ID (Entra: Identifier), the ACS (reply) URL (Entra: Reply URL) and, where your IdP accepts one, the SP metadata URL.

   The redirect URI and the ACS URL are the same endpoint — SAML and OIDC just name it differently.

2. Back in Resilic, choose the protocol and how you supply the metadata:

   • OIDC — your provider’s discovery URL. Use the tenant-specific one; for Entra ID that is https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration with your tenant ID. The common and organizations variants publish a placeholder issuer, so every sign-in would fail issuer validation.
   • SAML — the federation metadata URL or the pasted metadata XML.

3. For OIDC, also enter the client ID and secret from step 1. (SAML needs none — it trusts via the exchanged metadata and certificates.)

4. Save. Resilic sets up the connection. Make sure your IdP 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.

Renewing your identity provider’s certificate

With SAML, your identity provider signs every sign-in with a certificate that Resilic took from the metadata. That certificate has an expiry date — typically three years for Entra ID, often one year for other providers. Once it expires, every SSO sign-in fails until you supply the renewed certificate. It is exactly the kind of deadline that gets forgotten.

So Resilic keeps an eye on it:

• The Single Sign-On settings show IdP certificate valid until. From 30 days before expiry the line is marked as a warning, after expiry as an error.
• 30 days before expiry, every subscriber of the Single sign-on: certificate expiring category gets an email — once per certificate, not daily.

How to renew: roll out the new certificate at your identity provider first (in Entra ID under Enterprise applications → SAML signing certificate). Then resubmit the metadata — with a metadata URL, saving step 2 again is enough; with pasted XML, paste the updated XML. Resilic picks up the new certificate, shows the new expiry date and re-arms the reminder for the next cycle. While your IdP still signs with the old certificate, sign-in stays interrupted — so renew within the overlap window your provider offers.

With OIDC there is no such certificate: Resilic fetches your provider’s signing keys continuously via the discovery URL. What can expire there is the client secret — its lifetime is set by your identity provider and Resilic cannot read it. Note the expiry date when you create it (Entra ID allows up to 24 months) and enter the new secret in step 2 before the old one runs 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.