Enterprise Identity, Your Way

Every large enterprise has made substantial investments in its identity and access management infrastructure. Okta, Microsoft Entra ID, Ping - these are not incidental purchases. They represent years of policy configuration, integration work, and user adoption. They encode your organization's rules about who gets access to what, under what conditions, and for how long.

So when a new vendor arrives and expects you to manage a separate population of users in their own portal - with their own password policies, their own MFA, their own lifecycle - that is not a minor inconvenience. It is an ongoing operational cost, a compliance exposure, and a security risk. Identity silos are one of the most common reasons access persists after it should have been revoked.

The right question to ask any cloud database vendor is not whether they support SSO. It is how completely they integrate with the identity stack you already have.

The Problem With Parallel Identity Systems

Consider the offboarding scenario. An employee leaves your organization. Your HR system triggers a deprovisioning workflow. Their Okta account is disabled. Active Directory reflects the change. But the cloud database vendor they used for six months still has their credentials in a local account - untouched, still valid, still capable of connecting to production data.

This is not a hypothetical. It is the natural outcome of any vendor that manages its own user identities rather than federating to yours. The answer is not just SSO - it is the full lifecycle: provisioning, access governance, group membership synchronization, and automated deprovisioning. SingleStore Helios is built to support all of it.

Single Sign-On - SAML 2.0 and OIDC

SingleStore supports federated SSO via both SAML 2.0 and OpenID Connect (OIDC), with validated integrations for Okta, Microsoft Entra ID, Ping, and JumpCloud.

In either flow, the portal acts as a service provider. Your users authenticate at your identity provider - not at SingleStore. The token mechanics differ between the two protocols (detailed below), but in both cases the MFA, conditional access policies, and device posture requirements you have configured in your IdP apply automatically to SingleStore sessions.

How the SSO flow works

• SAML 2.0: SingleStore redirects the user to your IdP. Once the IdP authenticates them, SingleStore validates the signed SAML assertion and issues its own access and refresh tokens, valid for 7 hours. The authorization code used to exchange the assertion is one-time and invalidated after use, which blocks assertion replay.
• OIDC: SingleStore starts the authorization-code flow and redirects the user to your IdP. After the IdP validates the login, SingleStore issues its own access and refresh tokens. The session stays valid as long as the upstream login at your IdP does. Disable or revoke the user at your IdP and the next refresh fails.
• What SingleStore receives: Only the minimum identity information needed: user identity. Group membership is synchronized separately through SCIM (covered next), not via the SSO assertion. Your IdP retains control of credentials and authentication policy.SingleStore Helios implements SCIM 2.0 (RFC 7643/7644), allowing your identity provider to automatically synchronize users and groups - including status changes - in real time. When you add a user in Okta, they appear in SingleStore Helios. When you disable an account, access is removed. When you change group membership in Okta, SingleStore team membership changes along with the permissions that come with the team.

Automated Provisioning and Deprovisioning with SCIM

SSO solves the authentication problem. SCIM solves the lifecycle problem.

SingleStore Helios implements SCIM 2.0 (RFC 7643/7644), allowing your identity provider to automatically synchronize users and groups - including status changes - in real time. When you add a user in Okta, they appear in SingleStore Helios. When you disable an account, access is removed. When you change group membership in Okta, SingleStore team membership changes along with the permissions that come with the team.Documented integrations available for Okta and Microsoft Entra ID. Other SCIM 2.0-compliant IdPs are supported via SingleStore Support.

What SCIM 2.0 integration enables

• User provisioning and deprovisioning happen at a single point: your identity provider. There is no separate user management workflow in SingleStore.
• Groups in your IdP synchronize automatically to SingleStore Teams, which carry the corresponding RBAC controls. Add someone to the DBA group in Okta and they land in the mapped DBA Team in SingleStore, picking up whatever DBA-level permissions you have configured on that Team. Permissions are set on the Team in SingleStore, not derived from the IdP group, so the Team and its permissions must be configured before the SCIM sync does anything useful.
• User status is included in the sync. Suspended or deactivated accounts in your IdP will be removed from the SCIM target organization.

Multi-Factor Authentication - Your Policy, Your Enforcement

MFA in SingleStore Helios is designed to complement rather than duplicate the MFA you already enforce through your IdP.

For SSO users - the majority of enterprise users - MFA is handled by your identity provider. The conditional access policies, device trust, and step-up requirements you have configured in Okta or Entra ID apply directly to SingleStore sessions. An optional "Enforce MFA" toggle on the IdP connection adds Helios-native MFA on top for organizations that require an additional layer.

For non-SSO users, email-based MFA is enforced by default, with TOTP authenticator app support as an alternative. Users can register a trusted device for up to 30 days to reduce repeated prompts without eliminating the control entirely.

Machine Identity - Eliminating Static Credentials in Automation

Service accounts and automation pipelines are often harder to manage than human users - and more likely to carry long-lived static credentials that never rotate. SingleStore Helios addresses this through cloud IAM integration. For workloads running on AWS, Azure, or GCP, services can authenticate without any static database passwords or traditional password authentication.

Authorization remains governed by SingleStore RBAC regardless of how identity is established. The IAM role or JWT tells SingleStore who the caller is - SingleStore roles and privileges determine what they can do.

Human access to your database cluster, authenticated by your IdP

Password-less database authentication access to your Helios database cluster is supported via web login to your identity provider instead of traditional password authentication.. For Helios, this is handled with a helper that captures a JWT. This does require web validation on each access because the JWT is short-lived. 

A Maturity Model for Identity Integration

Not every organization will implement every capability on day one. Here is a practical progression:

Identity integration stages

• Stage 1 - Local accounts with MFA: Start here if you need to move fast with traditional password authentication.. Local username/password with email MFA enforced. Baseline security, manageable overhead.

• Stage 2 - SSO federation: Connect your IdP via SAML or OIDC. Your MFA and conditional access policies now apply. Single point of authentication for your users.

• Stage 3 - SCIM provisioning: Add automated lifecycle management. Users and groups are managed entirely at the IdP. Offboarding is reliable and immediate.

• Stage 4 - Machine identity: Replace service account passwords with cloud IAM tokens or short-lived JWTs. No static credentials in any pipeline or automation workflow.