Skip to main content
SAML / OIDC SSO is available on the Enterprise and Custom plans (see Billing & plans). Orgs that subscribed to a plan that included SSO before the current pricing keep it - grandfathered plans keep their features. Radar Cloud uses WorkOS for SSO. Owners configure their IdP self-serve via the WorkOS Admin Portal - Okta, Azure AD, Google, OneLogin, generic SAML, generic OIDC. On save, WorkOS provisions the connection and notifies the Radar Cloud control plane.

​
Two ways to route a sign-in to your IdP

  • By email domain. A person types their address on the sign-in page; if its domain is one your organization has verified, they are sent to your IdP. Set up below.
  • By your organization’s link. With SSO configured, app.radarhq.io/login/<handle> shows a sign-in page for your organization and sends whoever signs in there to your IdP, whatever their email domain - no domain to verify. See Per-organization sign-in link.
Most organizations use both. Which path applies to your situation is laid out in Sign-in and access. Connecting SSO adds a door; it does not close the Cloud sign-in page for members who already have an account. A Require single sign-on setting is not available yet.

​
Route by domain: verify your email domain

SSO routing needs your organization’s email domain. Add it under Settings → Organization → Domains (owner-only) before opening SSO setup - e.g. company.com for users signing in as alice@company.com - and verify it: the page shows a DNS-TXT record (verification_token=...) to publish at the domain you are verifying - for a subdomain, the guided setup gives the exact DNS host - and checks it in the background. A verified domain powers both SSO routing and domain auto-join; a domain that is pending or failed is claimed but inert until the record is in place. Already opened SSO setup before adding a domain (or added one later)? Add and verify the domain on the Domains page; it is registered with WorkOS when you add it, and its verification state refreshes from there. You don’t need to reopen SSO setup.

​
Set up SSO

Settings → Organization → SSO (owner-only). Click Open SSO setup (the button reads Manage SSO once a connection already exists):
  1. Radar lazy-creates a WorkOS organization for you (one per Cloud org) and opens the WorkOS Admin Portal in a new tab.
  2. Pick your IdP from the menu. WorkOS will walk you through the IdP-specific steps:
    • For SAML: SAML metadata URL or XML upload, attribute mapping.
    • For OIDC: discovery URL, client ID / secret.
    • For named IdPs (Okta, Azure AD): OAuth-style consent flow that handles the rest.
  3. Save. The SSO card flips to Connected, with the IdP name and the last sign-in that used it, after the first successful sign-in through the connection - that sign-in is what tells Radar the connection works.
After setup, users from your IdP sign in at app.radarhq.io/login by typing an address at a verified domain, or through your organization’s sign-in link. A new user whose sign-in WorkOS routes to your organization joins it with the Default invite role on first sign-in - no invitation needed; an existing member keeps their role.

​
Domain matching

SSO sign-ins are routed by email domain. The domains come from Settings → Organization → Domains and must match the domain(s) your IdP issues identities for - list and verify every domain your users sign in with. A domain is registered with WorkOS when you add it and routes sign-ins once verified; removing a verified domain stops routing its sign-ins through SSO and stops its auto-join. See Members for how the same list drives domain auto-join, and SSO for external users for contractors who sign in through your IdP with another employer’s address. Alongside domain routing, each org has a readable sign-in link that names the organization: app.radarhq.io/login/<handle> (e.g. app.radarhq.io/login/acme-corp). Opening it shows a “Sign in to Acme Corp” page and routes straight to your IdP - the user doesn’t type a domain or pick an organization. Manage it under Settings → Organization → SSO: the sign-in link card shows the link with a Copy button and lets you rename the handle. The handle is generated from your org name and is editable; handles are unique across Radar. The link is a routing hint only - it decides which IdP to send the user to, never who they are. The sign-in callback still derives the real identity from your IdP’s response. A wrong or stale handle falls through to the ordinary sign-in page with a notice that the link isn’t valid; a handle another organization has since taken routes to that organization’s sign-in, where your IdP is not involved. This link is what makes SSO work for users whose email domain isn’t yours - see SSO for external users.

​
Cluster access for new clusters

With SSO connected, Settings → Organization → SSO has a Cluster access setting (owner-only) that decides how new clusters grant Kubernetes access:
  • Hub roles (default) - the chart binds each Radar role to a Kubernetes role: owners get admin, members edit, viewers view.
  • IdP groups - new installs leave those bindings out, and only the bindings you write in Kubernetes RBAC grant access (usually to radar:idp:<group-id>). The install page shows a starter binding to apply. Until one exists, nobody - including you - sees the cluster’s resources in Radar; the cluster still connects.
Existing clusters are never changed. The setting applies to fresh installs only. When you connect a cluster that already runs Radar, turn on Already running Radar in this cluster? in the connect wizard to keep its bindings: the default command is a fresh install, and on an existing release it removes the tier bindings. If no IdP groups reach your clusters from your own session, the setting warns you: usually the groups attribute mapping is missing (see IdP group-based access). With IdP groups selected, the page also shows how to switch an existing cluster and lists clusters whose Radar is too old for it. See RBAC under Cloud mode. Your Radar role (owner / member / viewer) still decides what someone can do in Radar - members, billing, settings - in both modes.

​
What about JIT / SCIM provisioning?

  • JIT (just-in-time provisioning) - works today. The first time a user signs in via SSO, they’re created as a Cloud user, and a sign-in WorkOS routes to your organization joins it with the default role (domain auto-join does the same for verified domains).
  • SCIM - directory-based user / group sync. Included in the Enterprise and Custom plans; the provisioning endpoints are rolling out. Contact us if you need SCIM enabled for compliance today.

​
Disconnecting SSO

Owners can manage the connection through the WorkOS Admin Portal (the same link the SSO card opens). Removing the connection there stops new SSO sign-ins; existing sessions remain valid until cookie expiry. Disabling a user in your IdP does not remove their Radar organization membership automatically. Remove them from Settings → Organization → Members as well, and revoke their credentials. Existing requests and streams are not terminated.

​
Audit

The audit log records SSO portal launches as org.sso.portal_opened and membership provisioning as org_member.sso_joined. Changes inside the WorkOS portal do not emit a separate configuration-completed event.

​
Plan availability

SAML / OIDC SSO is included in the Enterprise and Custom plans. Orgs grandfathered on a legacy plan that included SSO keep it. Google / GitHub sign-in works on every plan, including Free.

​
See also