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, anyone signing in with an address on your verified domain is sent to your IdP.
You set this up yourself under Settings → Single Sign-On. Only an Owner or Admin sees this section.
Before you start
Section titled “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
Section titled “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.
Step 2 — Connect your identity provider
Section titled “Step 2 — Connect your identity provider”Once the domain is verified, connect your IdP:
- Choose the protocol (SAML or OIDC) and how you’ll supply the metadata — a metadata URL or pasted XML.
- 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.)
- 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.
- 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
Section titled “Step 3 — Test, then activate”- Run a test sign-in through your IdP to confirm the connection works end to end.
- Once the 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
Section titled “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.
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, SAMLmemberOf, 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.