Skip to content

saml-sso.md

Latest commit

 

History

History
57 lines (34 loc) · 3.63 KB

saml-sso.md

File metadata and controls

57 lines (34 loc) · 3.63 KB
Raw

D5: SAML SSO

RevAgent supports SAML 2.0 SSO via Supabase Auth. Configure your IdP (e.g. Okta, Azure AD) and map a tenant identifier so users land in the correct workspace.

1. Enable SAML in Supabase

  1. In Supabase Dashboard → your project → Authentication → Providers → SAML 2.0, enable SAML.
  2. Note the ACS URL and Entity ID and configure them in your IdP as the SP (Service Provider) endpoints.
  3. In the IdP, create a SAML app and set the Single sign-on URL (ACS URL) and Audience / Entity ID to the values Supabase shows.
  4. Download the IdP metadata (XML) or copy the Sign-in URL, Certificate, and (if needed) IdP Entity ID, and enter them in Supabase.

2. Map tenant to SAML attributes

To assign users to a RevAgent tenant (workspace), map an attribute from your IdP into Supabase app_metadata:

  1. In Supabase SAML provider settings, find Attribute mapping (or SAML attribute mapping).
  2. Add a mapping so the IdP attribute that holds the RevAgent tenant ID (UUID) is stored in app_metadata.tenant_id.

Example (conceptual; exact UI may vary):

  • Attribute name in Supabase: tenant_id
  • IdP attribute: e.g. http://schemas.revagent/tenant_id or a custom attribute you define in the IdP that contains the tenant UUID.

If your IdP sends a fixed value per org, configure that attribute in the IdP to the RevAgent tenant UUID for that org.

3. Link SAML users to RevAgent tenant

After the user signs in via SAML, Supabase creates or updates auth.users. RevAgent needs a row in public.users with tenant_id so the dashboard can resolve the workspace.

Option A — Automatic via app_metadata

If you mapped tenant_id in step 2, the web app can call the link API once after SAML login:

  • Endpoint: POST /v1/auth/saml/link
  • Headers: Authorization: Bearer <Supabase access_token> (from the session after redirect)
  • Body (optional): { "tenant_id": "<uuid>" }. If omitted, the API uses app_metadata.tenant_id from the JWT.

If the user already has a public.users row (by auth_user_id or id), the API returns 200 and does nothing. Otherwise it creates a row (or links an existing SCIM-provisioned user by email + tenant) so the user has a tenant.

Option B — Manual tenant_id in body

If you do not map tenant_id in the IdP, the client can call POST /v1/auth/saml/link with body { "tenant_id": "<uuid>" } after SAML login (e.g. on a “Select workspace” or post-login screen).

4. Web app flow

  1. User goes to Sign in and chooses Sign in with SSO (or you redirect to Supabase SAML sign-in URL).
  2. Supabase redirects to the IdP; user signs in; IdP POSTs to Supabase ACS URL; Supabase creates/updates the session and redirects back to your app (e.g. /auth/callback?next=/dashboard).
  3. Your app loads the session. If public.users has no row for this auth user, call POST /v1/auth/saml/link with the Supabase access token (and optional tenant_id in body). Then redirect to dashboard; the app will resolve tenant_id from public.users (by auth_user_id or id).

5. SCIM-provisioned users (D6)

If users are first created via SCIM (no Supabase user yet), they have a row in public.users with auth_user_id null. When they sign in via SAML for the first time, POST /v1/auth/saml/link finds them by email + tenant_id and sets auth_user_id to the Supabase user id, linking the accounts.

References