SSO: Enterprise Authentication for RuleSync
Enterprise organizations require SSO (Single Sign-On) for all SaaS tools — including RuleSync. SSO provides: centralized authentication (users log in once through the corporate identity provider — Okta, Azure AD, Google Workspace — and access all tools without separate credentials), centralized deprovisioning (when an employee leaves: disable their IdP account and they lose access to all tools, including RuleSync, immediately), compliance (SOC 2, ISO 27001 require centralized access management — SSO satisfies these controls), and audit trail (all authentication events logged in the IdP for security monitoring).
RuleSync SSO support: available on the Enterprise plan. Protocols: SAML 2.0 (standard enterprise SSO) and OIDC (OpenID Connect — modern, lightweight). Supported identity providers: Okta, Azure Active Directory (Entra ID), Google Workspace, OneLogin, Auth0, and any SAML 2.0 or OIDC-compliant IdP. The setup: typically 30-60 minutes, done by the organization's IT admin with support from RuleSync's enterprise team.
What SSO replaces: without SSO, developers authenticate to RuleSync with: email/password (a separate credential to manage), GitHub OAuth (convenient but not controlled by the IT admin), or GitLab OAuth. With SSO: all authentication goes through the corporate IdP. The IT admin: controls who has access. Access reviews: handled in the IdP, not in RuleSync. Offboarding: disabling the IdP account revokes RuleSync access automatically.
Step 1: SAML 2.0 Setup
In the RuleSync dashboard (Enterprise plan): Settings → Security → SSO → Enable SAML. RuleSync provides: the ACS URL (Assertion Consumer Service — where the IdP sends the SAML response), the Entity ID (RuleSync's identifier in the SAML exchange), and the metadata URL (for automated IdP configuration). Copy these values: they are entered into the IdP configuration.
In the identity provider (Okta example): Admin → Applications → Create App Integration → SAML 2.0. Enter: Single sign-on URL (the ACS URL from RuleSync), Audience URI (the Entity ID from RuleSync), Name ID format: EmailAddress, and attribute mappings (email, firstName, lastName — for user profile provisioning). Save. Okta provides: the IdP metadata URL, the IdP SSO URL, and the X.509 certificate. Enter these in RuleSync's SSO settings.
Test the connection: RuleSync → Settings → SSO → Test Connection. A new browser window: opens the IdP login page. Authenticate. If successful: RuleSync shows 'SSO connection verified.' If failed: check the ACS URL, Entity ID, and certificate. Common issues: mismatched ACS URL (trailing slash difference), incorrect Entity ID, and expired certificate. AI rule: 'Always test before enforcing SSO. A broken SSO configuration that is enforced: locks every user out. Test first. Enforce after verification.'
SSO enforcement: disables all other login methods. If the SSO configuration is wrong: every user is locked out. They cannot: log in with email/password (disabled). They cannot: log in with GitHub OAuth (disabled). They can only: authenticate through the (broken) IdP — which does not work. The fix: requires the break-glass admin account or direct database access by RuleSync support. Test the SSO connection thoroughly before enforcing. A test failure at the enforcement stage: catastrophic.
Step 2: OIDC Setup (Alternative to SAML)
OIDC (OpenID Connect): a simpler, modern alternative to SAML. In RuleSync: Settings → Security → SSO → Enable OIDC. RuleSync provides: the redirect URI (where the IdP redirects after authentication) and the client ID. In the IdP: create an OIDC application with the redirect URI and note the client ID, client secret, and discovery URL (the .well-known/openid-configuration endpoint).
Enter in RuleSync: the client ID, client secret, and discovery URL. RuleSync: auto-configures from the discovery URL (fetching the authorization endpoint, token endpoint, and JWKS). Test: Settings → SSO → Test Connection. The flow: same as SAML but uses tokens instead of XML assertions. AI rule: 'OIDC: simpler to configure than SAML (fewer fields, auto-discovery). SAML: more widely supported in legacy enterprise IdPs. Choose based on your IdP's recommendation.'
When to use OIDC vs SAML: OIDC: for modern IdPs (Auth0, Okta Universal Login, Google Workspace). The configuration: 3-4 fields + auto-discovery. Simpler and faster. SAML: for enterprise IdPs that require it (some Azure AD configurations, legacy on-premises IdPs). The configuration: more fields, manual certificate management. More complex but universally supported. AI rule: 'If your IdP supports both: use OIDC (simpler). If your IdP only supports SAML: use SAML. Both achieve the same result — centralized authentication.'
SAML setup: ACS URL, Entity ID, IdP SSO URL, IdP metadata URL, X.509 certificate, Name ID format, attribute mappings. 7+ configuration fields. OIDC setup: redirect URI, client ID, client secret, discovery URL. 4 fields. The discovery URL: auto-configures everything else (authorization endpoint, token endpoint, JWKS). If your IdP supports OIDC: use it. Fewer fields = fewer misconfiguration opportunities = faster setup.
Step 3: Team Provisioning and SSO Enforcement
Team provisioning: SSO can automatically create RuleSync accounts when users authenticate for the first time (Just-In-Time provisioning). The user: logs in through the IdP. RuleSync: creates their account using the IdP's user attributes (email, name). The user: assigned to the organization with the default role (Editor). The admin: can adjust roles after the first login. No manual account creation needed — users self-provision through SSO.
SSO enforcement: after SSO is configured and tested, enforce it for all users. Settings → SSO → Require SSO for all users. After enforcement: email/password login and OAuth login are disabled. All users: must authenticate through the corporate IdP. This ensures: no user can bypass SSO (all authentication is centralized and auditable). The enforcement: the final step after verification. AI rule: 'Enforce only after: SSO is tested, IT admin confirms the configuration is correct, and a rollback plan exists (in case the IdP has an outage — a break-glass admin account that bypasses SSO).'
Break-glass access: after SSO enforcement, maintain one admin account that can authenticate without SSO (email/password). This account: used only when the IdP is down (outage, misconfiguration). The break-glass account: stored securely (password in the organization's secrets manager), documented (IT knows it exists and how to access it), and audited (any use of the break-glass account triggers an alert). AI rule: 'SSO enforcement without a break-glass account: risks locking out the entire organization during an IdP outage. Always maintain one emergency admin account.'
The IdP (Okta, Azure AD) has an outage. All SSO login attempts: fail. Without a break-glass account: nobody can access RuleSync. Rule sync: stopped. CI checks: failing (cannot authenticate). With a break-glass admin account (email/password, stored in the organization's secrets manager): the admin logs in and can: disable SSO enforcement temporarily, manage rules during the outage, and re-enable enforcement when the IdP recovers. The break-glass: used once a year at most. Its existence: prevents a disaster.
SSO Setup Summary
Summary of setting up SSO for RuleSync.
- Protocols: SAML 2.0 (universal) or OIDC (simpler, modern). Choose based on IdP recommendation
- SAML: ACS URL + Entity ID from RuleSync → IdP config. IdP metadata + certificate → RuleSync
- OIDC: redirect URI from RuleSync → IdP config. Client ID + secret + discovery URL → RuleSync
- Test: always test before enforcing. Broken SSO enforcement = locked-out organization
- Provisioning: Just-In-Time. Users self-provision on first SSO login. Default role: Editor
- Enforcement: require SSO for all users. Disables password and OAuth login
- Break-glass: one admin account with password access for IdP outages. Stored securely. Audited
- Supported IdPs: Okta, Azure AD (Entra ID), Google Workspace, OneLogin, Auth0, any SAML/OIDC IdP