> ## Documentation Index
> Fetch the complete documentation index at: https://radarhq.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# SSO for external users

> Onboard contractors, partners, and guest users through SSO - including guests who keep their own employer email - using a per-organization sign-in link and a guest-only email rewrite.

You already give external contractors and partners access to your systems as **guests in your own identity provider** - added to your Microsoft Entra (or Okta, or generic SAML) tenant, but signing in with their employer's email like `dana@partner.com`. This page shows how those same guests sign into Radar Cloud through your IdP, land with exactly the access their IdP group grants, and keep their real address on file.

It builds on three pages you should read first:

* [SSO](/docs/cloud/sso) - the SAML / OIDC connection this rides on.
* [IdP group-based access](/docs/cloud/idp-groups) - how an IdP group becomes Kubernetes access.
* [RBAC under Cloud mode](/docs/cloud/rbac) - the deny-by-default posture external users need.

## Why the standard path can't route a guest

Radar routes each sign-in to the right organization by the **domain of the email** the person signs in with. That works for your own staff on `example.com`. It breaks for a guest who keeps their employer address:

1. The guest's domain (`partner.com`) isn't yours, so Radar can't match them to your organization.
2. Even routed straight to your IdP, the sign-in service rejects an out-of-domain guest address with an email-verification challenge.

Two pieces fix both, and the setup below configures them:

* A **per-organization sign-in link** that names your org, so routing never depends on the guest's email domain.
* A **guest-only email rewrite** in your IdP that lands guests on a subdomain you own and have verified (`ext.example.com`), so they are admitted with no challenge.

<Note>
  The end-to-end path: the guest opens your link, Radar routes to your IdP, the IdP rewrites the guest's email onto your verified subdomain, and Radar admits them and applies their group access. Their real address is preserved separately (see [The real address on file](#the-real-address-on-file)).
</Note>

## What an external user experiences

It feels like signing into any tool that uses their company login - no Radar password, no account to create.

* They open your readable link, `app.radarhq.io/login/acme-corp`, which shows a **"Sign in to Acme Corp"** page so they know they are in the right place.
* Clicking through routes them straight to your IdP sign-in - no password prompt, no "which organization?" picker, no domain to type.
* After authenticating, they land in Radar as a normal member carrying exactly the IdP groups they were assigned, and nothing else.

## Set it up

A one-time setup by an owner, then one step per contractor.

### 1. Connect SSO and verify your subdomain

Follow [SSO](/docs/cloud/sso) end to end and choose a **SAML** connection. While you are in setup, verify the subdomain you will rewrite guests onto (`ext.example.com`) - that verified subdomain is what lets Radar admit the rewritten address without a challenge.

<Warning>
  Use **SAML, not OIDC**. The guest email rewrite in the next step is a SAML claim transformation; an OIDC connection has no equivalent.
</Warning>

### 2. Configure your IdP

The examples below use Microsoft Entra; any SAML IdP works the same way. Open the Radar enterprise application in your tenant and set up the SAML basics, the guest-only rewrite, the groups claim, and the real-address claim.

1. **Pick SAML.** Enterprise applications → your Radar app → **Single sign-on → SAML**. Paste the **Identifier** and **Reply / ACS URL** from Radar's SSO setup screen into the Basic SAML Configuration.

2. **Split the email claim by user type.** In **Attributes & Claims**, edit the email address claim so members keep their real address and guests get the rewrite:

   | User type  | Source         | Value                                   |
   | ---------- | -------------- | --------------------------------------- |
   | Members    | Attribute      | `user.mail`                             |
   | All guests | Transformation | rewrite onto your subdomain (next step) |

   Order matters - the guest rule must not sit under a broader rule that would catch guests first.

3. **Build the rewrite.** On the guest row, chain `ExtractMailPrefix(user.mail)` then `Join()` with separator `@` and a constant equal to your verified subdomain. This turns `dana@partner.com` into `dana@ext.example.com` for guests only.

4. **Send the groups claim.** Return security groups **by Group ID** (the immutable object ID / GUID, not the display name). Radar maps each group's object ID to namespace access - see [IdP group-based access](/docs/cloud/idp-groups) for the exact claim and RBAC recipes.

5. **Carry the real address.** Add one more claim named `contactEmail`, source **Attribute `user.mail`**, with no condition, so Radar keeps each contractor's real address.

### 3. Set your organization handle and share the link

In **Settings → Organization → SSO**, the **Contractor sign-in link** card shows your readable link and lets you rename the handle. The handle is generated from your org name and is editable; copy the link and hand it to contractors. See [SSO](/docs/cloud/sso#per-organization-sign-in-link) for how the handle works.

### 4. Lock down default access

External users should get **only** what their IdP group grants. Getting there is two decisions - the **Cloud role** they land with, and the **chart's default tier bindings** - and both matter.

**A contractor's baseline access follows their Cloud role, not their groups.** The chart binds each role to a Kubernetes tier out of the box: `radar:owner` → `admin`, `radar:member` → `edit` (writes), `radar:viewer` → `view`. So the group-only outcome only holds if the contractor lands in a tier you have actually turned off.

<Warning>
  Disabling the **viewer** tier alone is not enough if contractors land as **members**. A contractor who domain-auto-joins gets your org's **Default invite role**, which is typically `member` - and a member keeps the `radar:member` → `edit` binding no matter what the viewer flags say. Put the group-only population in a tier you disable:

  * Either set the **Default invite role** (or the invite you send) to **viewer**, then disable the viewer tier, **or**
  * disable the tiers they can land in (`defaultRbac.member: false` as well as `viewer: false`) if members should also be group-only.
</Warning>

Then turn off the default binding for that tier in your `radar` Helm chart values, so a contractor lands in Radar but sees nothing until a group grants it. For a viewer-tier contractor that is `defaultRbac.viewer: false` **and** `clusterScopedRead.viewer: false` (both required - they gate different bindings). The flags, the per-tier model, and the full-IdP governance option are in [RBAC under Cloud mode](/docs/cloud/rbac#overriding-the-defaults) and [IdP group-based access](/docs/cloud/idp-groups#4-bind-the-groups-in-kubernetes-rbac).

<Note>
  These are cluster-install settings in the chart values where Radar runs, not a hub toggle. The Cloud role is set in Radar (invite role or Default invite role); the tier bindings are set in the chart.
</Note>

### 5. Require single sign-on

Once your IdP is connected, turn on **Require single sign-on** in **Settings → Organization → SSO** so members can't fall back to a password or magic link. Enabling it is only allowed from a session already signed in through your IdP, so it can't lock you out. Personal access tokens and automations stay exempt.

## Onboard and offboard

Per contractor, the whole flow is three steps you already know:

1. Add them as a **guest** in your IdP tenant - they keep their employer email, the same way you bring in any partner.
2. Put them in the **security group** that maps to the namespaces they should reach.
3. Send them your per-tenant link (`/login/<your-handle>`). That is all they need - no invite to accept, no password to manage.

To offboard, remove them from the **group** (revokes access) or from the **tenant** (revokes sign-in). No Radar-side step is required.

## The real address on file

Because a contractor signs in with the synthetic subdomain address, Radar stores their real one from the `contactEmail` claim and shows it in **Settings → Organization → Members**, with the sign-in identifier beneath it. That real address is also what an invitation sent to their employer email matches against. See [Members](/docs/cloud/members#contact-email-for-external-users).

## What each account carries

|                                | Employee (member)                            | Contractor (guest)                               |
| ------------------------------ | -------------------------------------------- | ------------------------------------------------ |
| Email Radar signs them in with | `dana@example.com`                           | `dana@ext.example.com`                           |
| Real address on file           | same                                         | `dana@partner.com`                               |
| Email-verification challenge   | none                                         | none - the subdomain is verified                 |
| Cloud role                     | `member` (or whatever you assign)            | a tier you have disabled, so baseline is nothing |
| Access                         | their `member` tier (`edit`) plus any groups | their groups only (after step 4)                 |

Once you have locked down default access (step 4), a contractor with no matching IdP group lands in Radar but sees nothing until they are added to a group. That is intended - access follows group membership, managed entirely in your IdP. This holds only when the contractor's Cloud role tier has its default binding turned off; otherwise they inherit that tier's access (for example a `member` keeps `edit`) regardless of their groups.

## Requirements for your Radar admin

* The connection must be **SAML** (the guest rewrite is a SAML claim transformation).
* The deployment's WorkOS JWT template must map the IdP's real-address attribute to a `contact_email` claim. Without it, the real address does not appear in Members and invitations sent to it don't auto-match.
* The `radar` Helm chart values control baseline RBAC (deny-by-default) in the cluster where Radar runs.

## Plan availability

SAML / OIDC SSO is included in the **Enterprise** and **Custom** plans (see [Billing & plans](/docs/cloud/billing)). Orgs grandfathered on a legacy plan that included SSO keep it.

## See also

* [SSO](/docs/cloud/sso) - SAML / OIDC self-serve and the per-organization sign-in link.
* [IdP group-based access](/docs/cloud/idp-groups) - the groups claim and the RBAC recipes external users rely on.
* [RBAC under Cloud mode](/docs/cloud/rbac#locking-down-for-security-conscious-orgs) - deny-by-default in depth.
* [Members & invitations](/docs/cloud/members) - the real address on file and invitation matching.