Skip to main content
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:

​
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.
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).

​
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 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.
Use SAML, not OIDC. The guest email rewrite in the next step is a SAML claim transformation; an OIDC connection has no equivalent.

​
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: 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 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.
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 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.
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.
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 and IdP group-based access.
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.

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

​
What each account carries

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). Orgs grandfathered on a legacy plan that included SSO keep it.

​
See also