SSO and SCIM
Federate identity into Helios with SAML 2.0 or OIDC, provision and deprovision users automatically with SCIM 2.0.
SSO and SCIM
Helios supports SAML 2.0 and OIDC single sign-on, and SCIM 2.0 for automated user provisioning. Both are configured per organization.
Helios speaks the standards rather than integrating per-vendor, so any SAML 2.0 or OIDC identity provider will connect. JumpCloud is the provider running in production today; if you're setting up another and something doesn't line up, tell us and we'll work through it with you.
Contact [email protected] to enable SSO for your organization. You'll receive a one-time setup link; opening it shows the values your identity provider needs and lets you submit your configuration.
SAML
Your IdP needs two values from Helios, both shown on your setup page:
| Field | Value |
|---|---|
| ACS URL (Assertion Consumer Service) | https://<helios-host>/api/v1/auth/sso/saml2/callback/<providerId> |
| Entity ID / Audience | https://<helios-host>/api/v1/auth/sso/saml2/sp/metadata |
You can supply your IdP's configuration three ways: a metadata URL, an uploaded metadata XML document, or manually (sign-in URL plus signing certificate).
JumpCloud publishes metadata advertising only the HTTP-POST binding. Helios initiates sign-in over HTTP-Redirect and handles this automatically — no change is needed on your side.
IdP-initiated sign-in works; users land on the Helios onboarding page.
OIDC
Supply your provider's issuer URL, client ID, and client secret. Register this callback URL with your provider:
https://<helios-host>/api/v1/auth/sso/callback/<providerId>Just-in-time provisioning
When SSO is configured and SCIM is not, users are provisioned on first sign-in:
- If the user has a pending invitation to the organization, they join with the role from that invitation.
- Otherwise they join as a
viewer— read-only at the account layer. An admin promotes them from there.
See roles and permissions for what each organization role means.
An invited user whose organization has SSO configured must sign in through SSO before accepting the invitation.
SCIM
SCIM 2.0 lets your identity provider create and remove Helios users automatically. Enable it per organization, then generate a bearer token from your organization settings.
| Field | Value |
|---|---|
| Base URL | https://<helios-host>/api/v1/auth/scim/v2 |
| Authentication | OAuth bearer token |
The token is shown once. Generating a new token replaces the old one immediately.
Helios advertises support for PATCH and filtering; bulk operations, sorting, and password change
are not supported.
What SCIM provisions
Users. A user created through SCIM joins the organization with the member role.
Groups are not supported. There is no /Groups endpoint, and there is no group-to-role mapping.
Every SCIM-provisioned user receives the member role, and an admin must promote them from there.
Deprovisioning
Setting active: false does not deactivate a Helios user. Many identity providers deprovision by
patching a user to inactive; Helios ignores that attribute. Only a SCIM DELETE on the user removes
their access, ending their sessions and deleting the user.
Configure your IdP to send DELETE on deprovisioning, and verify it does before relying on it.
SCIM and SSO together
When SCIM is enabled for an organization, SCIM becomes the sole authority on membership. Just-in-time provisioning is skipped and manual invitations are rejected. Add and remove people in your identity provider.
What Helios does not do today
Being explicit, so you can plan around it:
- No domain verification. Helios does not verify ownership of your email domain.
- No organization-wide SSO enforcement. An existing member who also has a password or social login can still use it. SSO is enforced when accepting an invitation, not on every sign-in.
- No user-visible audit log.
Related
- Roles and permissions — organization roles and API keys.
- Projects and sharing — granting access once people are in.
Last updated on
Variables and secrets
Variables are plaintext configuration passed to your agents. Secrets are envelope-encrypted values that never enter an agent's context.
Advanced
Techniques for reliable unattended agents: scoping the task, guarding against unwanted events, persisting state, and calling Helios from your own code.