ProbeRun

Docs

Set up SAML single sign-on

On ProbeRun Cloud your team can sign in through your own SAML identity provider (Okta, Entra ID, Google Workspace, or any SAML 2.0 IdP). The connection lives at WorkOS, the sign-in service ProbeRun Cloud uses, on the WorkOS organization ProbeRun bound to your team. You set it up yourself in the WorkOS Admin Portal; ProbeRun hands you the link. SAML is included on the plans the pricing page lists with it; a self-hosted server signs in through your own OIDC identity provider instead.

Before you start

  • You are an Admin of the team, signed in as yourself. Developers, Viewers and API keys (an Admin-role key included) are refused with 403.
  • Your plan includes SAML. If it does not, both calls below answer 402 with code entitlement_required and entitlement sso.saml.
  • Your team is bound to your organization. ProbeRun does this once; if the Single sign-on panel says your team is not bound yet, write to support@proberun.com. Until then the link request answers 409 org_binding_required.

1. Verify your email domain first

A SAML connection only routes sign-ins once your domain is verified: when someone types an email on your domain at the sign-in page, WorkOS sends them to your IdP. On the dashboard, open Team > Single sign-on and choose Verify domain: it asks for a fresh link and opens the WorkOS page in a new tab (each link lasts five minutes). Set up SAML does the same for the connection. The section also shows each connection’s and domain’s state, and says “no domain is verified yet” while an active connection still routes nobody.

The same request, made to the API as a signed-in Admin:

POST /team/sso/portal-link
{"intent": "domain_verification"}

200 {"link": "https://...", "expires_in_seconds": 300}

Open the link within five minutes and follow the DNS steps. The link is a one-time credential for your WorkOS setup: ProbeRun returns it once and never stores or logs it. The request is recorded in your audit log as sso.portal_link_issued with the intent and your organization id, never the link.

The request cannot choose an organization: a body naming one is refused with 422, and ProbeRun always uses the organization bound to your team.

2. Connect your identity provider

Request a link with {"intent": "sso"} and follow the Admin Portal’s steps for your IdP. Nothing changes on the ProbeRun sign-in page: it keeps its single “Continue with single sign-on” button, and WorkOS routes your people to your IdP by their email domain.

3. Check the connection

GET /team/sso reads the state from WorkOS at that moment:

{"organization_bound": true, "state": "checked",
 "connections": [{"type": "OktaSAML", "state": "active", "vendor_state": null}],
 "domains": [{"domain": "example.com", "state": "verified", "vendor_state": null}],
 "checked_at": "...", "correlation_id": null}
  • A connection is active only when WorkOS says exactly that; anything else is inactive, with WorkOS’s own value in vendor_state.
  • If WorkOS cannot be reached, state is check_failed with a correlation id to quote to support. That means “could not check”, never “no connection”.
  • A link request while WorkOS is unreachable answers 502 sso_provider_unavailable with a correlation id.

Who gets in

SAML changes how your people prove who they are, not who is admitted to your team. After a SAML sign-in, a person is admitted exactly as before: an existing membership, an invitation, an admission group, or, only if you turned it on, automatic provisioning (JIT) at your team’s default role. Only sign-ins from your bound organization count.

  • JIT off (the default): a new person who signs in through SAML is not added; invite them.
  • JIT on: a new person from your organization joins at your default role, recorded as member.provisioned.
  • An unverified email is not linked to an invitation.
  • A sign-in from an organization bound to another team never enters yours, even if your team has no organization bound yet: another team’s IdP cannot vouch for your people’s email addresses. Write to support@proberun.com to bind your team to your organization; a bound team admits only its own organization.

Offboarding: remove the person in your IdP (or from the organization in WorkOS); they lose access at their next sign-in. To end their current sessions at once, use Revoke sessions or remove the member in ProbeRun.

Requiring SSO

Requiring SSO is a setting on your WorkOS organization (its domain policy), applied by ProbeRun on request (write to support@proberun.com). When it is on, people with an email on your verified domain can only sign in through your IdP. ProbeRun itself does not refuse other sign-in methods: where the domain policy does not require SSO, and for people whose email is on another domain (contractors, guests), password, Google and email-link sign-in stay open.