Skip to main content
Two separate questions decide how someone gets into your Radar Cloud organization, and the pages in this section answer them one feature at a time. Keep them apart and the rest is simple:
  1. How does a person prove who they are? The Cloud sign-in page, or your identity provider through SSO.
  2. How does that person become a member of your organization? An invitation, auto-join on a verified email domain, or signing in through your organization’s own link.
The two questions are decided separately, and most organizations use more than one answer to each. Start here, then follow the link for the piece you need.

​
First: Cloud or self-hosted?

Everything below is about Radar Cloud (app.radarhq.io). A self-hosted Hub does not use WorkOS or any of it: people sign in with your OIDC provider directly, plus a permanent break-glass admin account. The first person to sign in becomes owner, later people join with the default role you configure, and owners manage roles from there. See Self-hosted authentication and stop reading this page.

​
How people prove who they are

  • The Cloud sign-in page - the methods offered there (an emailed code, and the providers Radar Cloud enables). Nothing to set up on your side.
  • Your identity provider through SSO - SAML or OIDC, connected self-serve from Settings on the Enterprise and Custom plans. See SSO.
Connecting SSO adds a door; it does not close the others. A Require single sign-on switch is not available yet, so a member who already has an account can still use the Cloud sign-in page.

​
How people become members

Three paths. They can all be on at once; only the third involves your identity provider. The third path is worth stating plainly: whoever WorkOS admits to your organization becomes a member - through your IdP’s connection, or through any other sign-in method routed in your organization’s scope. Radar adds no gate of its own there, and the organization-wide auto-join switch does not affect it (it governs domain-based joining only). Your identity provider’s admission policy is the gate, which is exactly what makes this the right path for contractors and guests.

​
What a verified domain does

A domain you add under Settings → Organization → Domains and verify with one DNS-TXT record (at the domain you are verifying, not its parent) does three separate things:
  • Routes SSO sign-ins, once SSO is configured. A person who types an address at a verified domain on the sign-in page is sent to your IdP. Without a verified domain, your organization’s sign-in link routes them instead.
  • Makes auto-join possible for addresses at that domain (with the switches above).
  • Is where rewritten guest addresses land, if you onboard external users through the subdomain alternative - a verified subdomain such as ext.example.com.
A domain that is added but not yet verified is claimed and does nothing until the record is in place.

​
Where “verified email” comes from

Radar trusts WorkOS’s verification status for the address. An address your IdP asserts through SSO at a domain you verified arrives verified, and so do sign-ins WorkOS can verify on its own (an emailed code you entered, or a provider that vouches for the address). When WorkOS decides an address still needs proving - for example an SSO assertion for an address outside your verified domains - it emails a code and Radar collects it. That is the normal experience for a guest who keeps their employer email; the guest flow’s subdomain alternative avoids it, because an address at a verified domain, asserted by your connection, is not challenged.

​
On top of any of the above

  • Cluster access that follows your directory groups. SSO plus a groups claim from your IdP, passed through to Kubernetes as radar:idp:<group> subjects you bind yourself. Bindings only add permissions: the baseline Cloud role still grants what it grants unless you turn that tier’s defaults off. See IdP groups and RBAC.
  • Guests who keep their employer email. They sign in through your organization’s link with their real address, confirm it with an emailed code, and join with the default role; OIDC or SAML, your choice. If you would rather they never see the code, the documented alternative rewrites guests onto a subdomain you verified and carries the real address as a separate claim; that recipe is written for a SAML connection. See SSO for external users.

​
SAML or OIDC?

Either: your IdP’s choice, for employees and guests alike. Only the subdomain-rewrite alternative for guests is documented for SAML. And note that “OIDC” on a self-hosted Hub is a different mechanism entirely - a direct connection with no WorkOS - so the Cloud SSO pages do not apply there.