Skip to content
Book a demo

Atlas documentation

All documentation
Documentation

Single sign-on

On this page

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

  1. Claim: Your email domain

  2. Configure: The identity provider

  3. Test: The connection

  4. 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.

  1. Go to Settings > Single Sign-On and add the domain (for example example.com).

  2. Adverity Atlas shows a DNS TXT record to publish.

  3. 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:

Scroll horizontally to see the full table.

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:

Scroll horizontally to see the full table.

Attribute

Default

Email

urn:oid:0.9.2342.19200300.100.1.3

Display name

urn:oid:2.16.840.1.113730.3.1.241

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.

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

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?