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 OIDC / 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, with their real employer address, and land with exactly the access their IdP group grants. It builds on three pages you should read first:
  • SSO - the OIDC / SAML connection this rides on. Either protocol works here; pick whichever fits how you run your IdP.
  • IdP group-based access - how an IdP group becomes Kubernetes access.
  • RBAC under Cloud mode - 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 the normal login can’t match them to your organization.
  2. Their address is outside your verified domains, so the sign-in service cannot take your IdP’s word for it and asks the guest to confirm it with a one-time code.
Two things address this, and the setup below covers them:
  • A per-organization sign-in link that names your org, so routing never depends on the guest’s email domain.
  • The emailed code. Radar collects it and completes the sign-in, so an out-of-domain guest is admitted on their real address (see The email code).
The end-to-end path: the guest opens your link, Radar routes to your IdP, they authenticate there, confirm their email with a one-time code, and land in Radar with their real address and their group access.

​
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 “which organization?” picker, no domain to type.
  • They enter the code emailed to their address on the “Enter your verification code” screen (see The email code).
  • They land in Radar as a normal member carrying the IdP groups they were assigned.

​
Set it up

A one-time setup by an owner, then one step per contractor.
SSO is a paid feature, on the Enterprise and Custom plans (see Billing & plans). Until your org is on a plan that includes it, Settings → Organization → SSO shows only an upgrade prompt - the connection setup, the org handle, and the sign-in link card won’t appear yet. Upgrade first, then the steps here become available.

​
1. Connect SSO and send the groups claim

Follow SSO end to end to connect your IdP. OIDC is the recommended default; SAML works the same way for this page. Then configure the groups claim so each guest’s security-group membership reaches Radar - see IdP group-based access for the claim setup and the RBAC recipes. Without the groups claim, a guest signs in but no group reaches the cluster and their group-based access stays empty. Two Entra details that catch people, whichever protocol you chose:
  • Send groups by ID. Return security groups by the immutable object ID (GUID), not the display name, under a claim named plain groups. Then, in Radar’s SSO setup portal, open Attribute mappings and map groups → groups; without that mapping the claim is silently ignored.
  • Let the contractor use the app. If the enterprise app has Assignment required = Yes (check Properties), anyone not assigned is rejected by Entra before any sign-in reaches Radar. Either assign the contractor’s group under Users and groups, or set it to No. The onboarding steps below assume the group is assigned.
SSO setup involves long round-trips to your IdP admin console, and the hosted setup link can time out while you are away. If it shows “This page isn’t available,” reopen Manage SSO from Settings → Organization → SSO to get a fresh link and continue.
In Settings → Organization → SSO, the sign-in link card shows your readable link, app.radarhq.io/login/<handle>, and lets you rename the handle. Copy it and hand it to contractors - it routes them straight to your IdP regardless of their email domain. The normal login page cannot route an out-of-domain guest, so they must use this link. See SSO for how the handle works.
Renaming the handle changes the link. The old one stops routing to your organization - it lands on the ordinary sign-in page with “This sign-in link isn’t valid”, or, if another organization later takes that handle, on their sign-in page - and neither can route your guest. If you have already shared the link with contractors, re-share the new one.

​
3. 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 joins through your link gets your org’s Default role (Settings → Organization → General, under “How people join”), 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 role to viewer before they first sign in (a contractor joins through the link with that role, and an invitation accepted afterwards does not change it; you can also change their role on the Members page), then disable the viewer tier, or
  • if members should also be group-only, disable the member tier too: cloud.defaultRbac.member: false.
Then turn off that tier in your radar Helm chart values, so a contractor lands in Radar but sees nothing until a group grants it. Disabling a tier removes both of its default bindings - the namespaced role and the cluster-wide infra read (Nodes, PVs, …) - and the flag lives under cloud::
Set it with --set cloud.defaultRbac.viewer=false if you prefer. Note the cloud: parent: Helm ignores mistyped keys silently, so a wrong path looks like it applied but leaves the contractor with view plus cluster-wide read. (cloud.defaultRbac.clusterScopedRead.<tier> is a separate switch for keeping a tier on but dropping only its infra read; it is not needed here.) The flags, the per-tier model, and the full-IdP governance option are in RBAC under Cloud mode and IdP group-based access.
To leave the tier bindings out of every new cluster instead of editing each one, set Settings → Organization → SSO → Cluster access to IdP groups (SSO). Either way, Radar Cloud’s own background identity (radar:system) keeps a read-only binding for alerts and the timeline; contractors never carry that group.
These are cluster-install settings in the chart values where Radar runs, not a hub toggle. The Cloud role is set in Radar (the invite you send, or the Default role under Settings → Organization → General); the tier bindings are set in the chart.

​
4. Know what SSO does not do yet

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 switch is not available yet. Until it is, the lock-down in step 3 - default Kubernetes bindings turned off, group bindings carrying the real permissions - limits what a stray sign-in can reach in your clusters; Cloud-side permissions (members, billing, SSO, cluster lifecycle) still follow the Cloud role the account holds.

​
The email code

A contractor’s address is outside the domains you verified, so the sign-in service cannot accept your IdP’s assertion of it on its own. After they authenticate with your IdP, it emails them a one-time code; they enter it on the “Enter your verification code” screen, and Radar completes the sign-in. Expect it on the first sign-in, and it may be asked for again on later ones.
A guest whose IdP account is passwordless (for example a personal Microsoft account added as a guest) may also receive a sign-in code from Microsoft - that one is your IdP’s own step, separate from Radar’s, and is controlled on your side.

​
Alternative: land guests on a subdomain you own

If you would rather guests never see the code, or you want their Radar identity to live on your own domain, your IdP can rewrite a guest’s address onto a subdomain you have verified in Radar (ext.example.com). An address at a verified domain, asserted by your connection, is admitted with no challenge. The costs: the recipe below is a SAML claim transformation in the Entra UI (we have not documented an OIDC equivalent), the subdomain has to be verified under Settings → Organization → Domains, and the contractor’s real address then travels as a separate claim so Radar can show it. Everything else on this page - the link, the lock-down, onboarding - is the same.
The subdomain only needs to exist and be verified - it is a subdomain of a domain you already own. You do not create mailboxes on it, and no mail is ever delivered to it. The rewritten addresses (dana-partner.com@ext.example.com) are sign-in identifiers only; each contractor’s real, reachable address is kept separately on file. Leave the subdomain unverified and a rewritten guest is challenged to prove an address that receives no mail, and cannot get in.
The examples use Microsoft Entra; any SAML IdP works the same way. Open the Radar enterprise application in your tenant:
  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, and keep it unique per guest. The rewritten address becomes the guest’s identity, so it must be distinct for every guest - fold their whole employer address into the local part, not just the mailbox name, so two people are never merged. Entra’s only transformation that can do this is RegexReplace() (there is no plain Replace()). On the guest row, set: That turns dana@partner.com into dana-partner.com@ext.example.com, and dana@other.com into dana-other.com@ext.example.com, which keeps the two apart. It is not collision-proof in theory - a-b@c.com and a@b-c.com both become a-b-c.com@ext.example.com - so if that matters to you, use a longer separator that is unlikely in a real address, such as _at_. Use Entra’s Test transformation to confirm the output before you save.
    Do not rewrite to just the mailbox name (ExtractMailPrefix(user.mail) on its own). Two guests with the same name at different employers - dana@partnerA.com and dana@partnerB.com - would both become dana@ext.example.com and collapse into a single Radar identity: whoever signs in second lands in the first person’s account. Folding the source domain into the local part keeps guests apart.
  4. Send the groups claim as in step 1 above - by object ID, under a claim named plain groups. By default Entra emits it under a namespaced URI (http://schemas.microsoft.com/ws/2008/06/identity/claims/groups); in the group claim’s Advanced options, tick Customize the name of the group claim and set the name to groups with the namespace left blank.
  5. Carry the real address. Add one more claim, source Attribute user.mail, with no condition, so Radar keeps each contractor’s real address. Set its Name to contactEmail with the Namespace left blank - the same rule as the group claim, so it emits as plain contactEmail and matches the mapping in the next step (a claim under a namespace URI won’t match).
  6. Map the attributes on the Radar side. In Radar’s SSO setup portal, open Attribute mappings → Edit attribute mappings and set both, or they silently stay empty and nothing flows:
    • groups → groups (without this, no group reaches the cluster and RBAC is inert).
    • contact_email → contactEmail (without this, the real address never appears in Members).
    The setup portal may suggest creating groups/contactEmail as Microsoft Graph directory-extension properties. You don’t need that path - the SAML claims you added above are enough. Map the attributes to those claim names and skip the Graph API.
On this path the contractor signs in as dana-partner.com@ext.example.com, Radar shows dana@partner.com from the contactEmail claim on top of it in Members, and an invitation sent to the real address matches through that claim. The deployment’s WorkOS JWT template must map the claim to contact_email for that to work; it does on Radar Cloud.

​
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, do both:
  • Remove them in your IdP - from the group to drop their group access (it takes effect when their Radar session next refreshes its token, not instantly), or from the tenant to stop them authenticating through your IdP at all.
  • Remove them from Settings → Organization → Members. Their Radar account and membership outlive your IdP: the same person can still reach the Cloud sign-in page with an emailed code to their address, and an existing membership admits them with whatever Cloud role it holds.
Neither step is enough alone. Removing them from Members ends the membership, but whoever your IdP admits through your organization’s link joins again on their next sign-in, with the default role - so if they are still a guest in your tenant and still assigned to the app, they are back in. Removing them in the IdP stops that, but leaves the membership they already have.

​
Tokens and AI tools

IdP groups travel with the signed-in session - the web app and its built-in AI assistant carry them to the cluster. A personal access token does not: anything that authenticates with one (a script, an external AI agent connected over MCP) reaches the cluster with the Cloud role’s bindings and any binding on the user itself, but nothing granted through a group. A contractor whose access comes entirely from IdP groups gets that access in the web app, not through a token.

​
The real address on file

Contractors sign in with their real employer address, so that address is what appears in Settings → Organization → Members and what an invitation sent to their employer email matches against. If your IdP also asserts a separate contactEmail claim (the subdomain alternative relies on it), Radar keeps it and shows it on top. See Members.

​
What each account carries

Once you have locked down default access (step 3) and no other binding names them, 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 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 IdP connection (OIDC or SAML) must send a groups claim, mapped in the SSO setup portal, for group-based access to work (see IdP group-based access).
  • The radar Helm chart values control baseline RBAC in the cluster where Radar runs. The default tier bindings are on; deny-by-default is what you opt into by disabling them (step 3).

​
Plan availability

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