SiftPulse SiftPulse
Try demos Compare Blog Changelog ROI Enterprise Pricing Autonomous AI Install on GitHub →
Security · Enterprise

SAML / SSO for SiftPulse

Last updated: August 18, 2026

Contents

  1. Current authentication model
  2. SAML / SSO rollout sequence
  3. First-install migration window
  4. How to flag a requirement

1. Current authentication model

SiftPulse today has no separate credential store. All authentication flows through one of two existing channels, and neither of them is SAML/SSO.

  • GitHub App installation tokens. Code-host access (GitHub, GitLab, Bitbucket) is governed by per-installation OAuth tokens issued by GitHub itself. SiftPulse stores those tokens encrypted, never logs them, and never sees a customer GitHub password — installing the GitHub App is the act of granting access. This is the same model described on /security — Access control.
  • Dashboard magic link. The customer dashboard at /app uses email magic-link authentication only — no passwords, no username store, no SAML/SSO connector. Sign-in links are signed tokens stored hashed in the dashboard_sessions table; the session cookie is HMAC-SHA256 signed (sp_session), httpOnly, and SameSite=Lax. Sessions expire after 7 days of inactivity.
  • No SAML/SSO identity-provider connector. There is no IdP metadata ingestion, no SAML response processing, no SCIM provisioning call anywhere in the SiftPulse stack today. We do not stand up a SAML SP, we do not own a user directory, and we do not authenticate users against a customer's identity provider. Any of those statements changing is what the roadmap section below describes.

Because there is no separate credential store, the full permission scopes, data-handling details, retention windows, and GDPR posture are the same surfaces that already live on /security — that page is the authoritative source. This page exists to answer the SAML/SSO follow-up question directly.

2. SAML / SSO rollout sequence

SAML/SSO + SCIM provisioning is targeted for Q1 2027, matching the timeline already published on /enterprise — Roadmap. The rollout ships per-organization, not as a global flip, so pilot teams can opt in and we can validate the migration model before opening it broadly.

Identity providers we are integrating first, in priority order:

  1. Okta. Most common among current pilot teams; integration begins first.
  2. Microsoft Entra ID. Second tier — the standard IdP for Microsoft-shop enterprise customers.
  3. Google Workspace. Third tier — covered for the segment that uses Workspace as the primary directory.
  4. JumpCloud / OneLogin. Second-pass tier — targeted after the top three are stable, gated on inbound demand.

Q1 2027 SAML/SSO + SCIM ship in the same release. SCIM provisioning rides alongside the SP integration so an admin can provision and de-provision dashboard users without manual seat management. Magic-link remains the fallback path during the cutover window.

3. First-install migration window

The first time a Team-tier admin enables SSO at the organization level in dashboard settings, existing users keep working magic-link until their first successful SSO sign-in. There is no flag day; the migration is graceful.

Enable SSO at the organization level

A Team-tier admin enables SSO from organization settings — IdP metadata upload, ACS URL, and entity ID are surfaced in the same panel as the installation token. Once enabled, the dashboard sign-in screen offers SSO as the primary path, with magic-link as the fallback path.

Existing users keep working magic-link

Until an existing dashboard user successfully signs in via SSO for the first time, their magic-link flow continues to work. There is no forced password reset and no forced re-authentication, so an enterprise cutover does not produce an outage.

Roll back to magic-link-only at any time

An admin can disable SSO and return the organization to magic-link-only without data loss. Existing dashboard sessions that were issued before the SSO switch remain valid through their original 7-day TTL — we do not invalidate sessions on the SSO toggle.

4. How to flag a requirement

If SAML/SSO is a hard requirement for your procurement review and you cannot wait for the Q1 2027 release, the fastest paths to reach the team are:

  • Submit a custom-eval request via /enterprise — Request a custom eval with SSO in the use-case line so it reaches the right inbound queue.
  • Email enterprise@siftpulse.com directly. Pilot teams that flag SSO as a procurement gate are prioritized in the rollout order above.

Need something else — SOC 2 evidence, DPA, on-prem status? Email security@siftpulse.polsia.app or revisit /security for the full permission scopes and data-handling details.

Samples Compare Customers Benchmark Enterprise Pricing Changelog Blog Security Status Support FAQ How it works ROI Calculator Privacy Terms
GitHub X LinkedIn
SiftPulse AI-powered PR review and issue triage — built for developer teams that move fast.