Single sign-on¶
Let your team sign in to Adverity Atlas through your own identity provider using SAML 2.0, so access follows the accounts and policies you already manage. Found at Settings > Single Sign-On.
Prerequisites¶
Admin role at the tenant level.
A SAML 2.0 identity provider (Okta, Entra ID, Google Workspace, OneLogin, and similar).
Control of the DNS records for the email domain you intend to claim.
How it fits together¶
Claim: Your email domain
Configure: The identity provider
Test: The connection
Enable: Then optionally enforce
Each step is reversible, and SSO stays inactive until you explicitly enable it, so you can set the whole thing up without affecting anyone signing in.
Step 1: Claim a domain¶
A domain claim proves you control the email addresses SSO will cover.
Go to Settings > Single Sign-On and add the domain (for example
example.com).Adverity Atlas shows a DNS TXT record to publish.
Add that record with your DNS provider, then click Verify.
Verification can take a few minutes to propagate. A domain can be released later if you no longer want it covered.
Step 2: Configure the identity provider¶
Configuration takes either the IdP’s metadata XML, the quickest route, since it carries every value at once, or the individual fields:
Field |
Description |
|
|---|---|---|
Metadata XML |
The IdP’s SAML metadata document. Fills in the fields below automatically. |
Optional |
Entity ID |
The IdP’s unique identifier |
Required |
SSO URL |
Where Adverity Atlas sends authentication requests |
Required |
SLO URL |
Single logout endpoint |
Optional |
X.509 certificate |
The IdP’s signing certificate, used to validate assertions |
Required |
Adverity Atlas publishes its own SAML metadata for you to hand back to the IdP, download it from the same page.
Attribute mapping¶
SAML assertions carry user details as attributes, and providers name them differently. Defaults follow the standard OIDs:
Attribute |
Default |
|---|---|
|
|
Display name |
|
Override them if your IdP sends different attribute names.
Just-in-time provisioning¶
With JIT provisioning on, someone who authenticates successfully but has no Adverity Atlas account gets one created on first sign-in. You set the default role and default workspace they land in.
The default role offers only the lower three rungs, Viewer, Analyst, and Editor. Knowledge Manager and Admin are deliberately not offered: granting either automatically from a SAML assertion would let a change in your IdP hand out approval or administrative rights.
Note
JIT provisioning means anyone your IdP authenticates for a claimed domain can obtain an account. Keep the default role at Viewer unless you specifically want new arrivals to be able to change things, or at Analyst if they should be able to use chat straight away. See Members and roles for what each role covers.
Step 3: Test¶
Test connection runs a full authentication round trip and reports what came back, without changing how anyone signs in. Use it after every configuration change, a certificate typo surfaces here rather than at the moment your team is locked out.
Step 4: Enable and enforce¶
These are two separate switches, and the order matters:
Enable: Turns SSO on as an option. Password sign-in keeps working. Anyone with an email on a claimed domain can use either
Enforce: Makes SSO the only route for claimed domains. Password sign-in stops working for those users
Warning
Enforce only after a successful test and at least one successful real sign-in. If the IdP is misconfigured when you enforce, no one on that domain can sign in, including you. Keep an admin account on an unclaimed domain until you are confident.
Both switches are reversible. Enforcement can be lifted, and the whole connection deleted, which returns everyone to password sign-in.
Permissions¶
Tenant Admin only. Members cannot see or change SSO configuration.
What’s next?¶
Members and roles, the roles JIT provisioning assigns
Audit logs, sign-in events and configuration changes