Single Sign-On (SSO)

Single Sign-On (SSO)

SkySaver supports federating login through your own identity provider — Okta, or any other SAML 2.0 or OIDC provider. Once configured, anyone signing in with an email address on a registered domain is redirected straight to your identity provider instead of using a SkySaver password.

Prerequisites

  • Admin access to your identity provider (e.g. an Okta admin who can create a new SAML or OIDC application).
  • The manage:project or org:poweruser permission scope in SkySaver (see RBAC).

Enabling SSO

Step 1: Navigate to the SSO tab

Navigate to Tenant Management and click the SSO tab.

Step 2: Choose a protocol

Select SAML 2.0 or OIDC, depending on how your identity provider application is configured.

Step 3: Fill in your identity provider’s details

For SAML:

FieldDescription
Metadata URLThe metadata URL published by your SAML application.
Or paste Metadata XMLAlternatively, paste the raw IdP metadata XML directly. Provide only one of Metadata URL or Metadata XML.
Email Attribute NameThe name of the SAML assertion attribute that carries the user’s email address (commonly email, but check your identity provider’s app configuration — this must match exactly or sign-in will fail).

For OIDC:

FieldDescription
Issuer URLYour identity provider’s OIDC issuer URL.
Client IDThe OIDC client ID for the application.
Client SecretThe OIDC client secret. Write-only — once saved, it is never displayed again. Leave blank on later edits to keep the current secret unchanged.

Step 4: Add your email domain(s)

Add every email domain that should route to this identity provider (e.g. acmecorp.com). A domain can only be registered to one project — if it’s already in use elsewhere, you’ll see a conflict error.

Step 5: Save

Click Enable SSO. New sign-ins from a registered domain are redirected to your identity provider from that point on.

Default access for new SSO users

The first time someone signs in through your identity provider, SkySaver automatically grants them read-only access — they don’t need to be invited first. If you want someone to have elevated or custom permissions from their very first login, invite them by email under Managing Users before they sign in for the first time: an existing invitation is never downgraded by the automatic read-only grant.

A note on users invited before SSO was enabled

If someone was already invited (and has a SkySaver password) before you enabled SSO for their domain, their very first sign-in through the identity provider may occasionally show an error — this is a known one-time quirk in how the identity provider link gets established. If this happens, simply sign in again; subsequent logins are unaffected.

Removing SSO

Click Remove SSO on the SSO tab. Affected users will fall back to signing in with a SkySaver password. Existing user permissions are not changed by removing SSO.

Troubleshooting

IssueCauseSolution
Login fails immediately after enabling SSOEmail Attribute Name (SAML) doesn’t match what your identity provider actually sendsCheck your identity provider’s SAML app configuration for the exact assertion attribute name carrying the user’s email, and update the field to match
“Domain already registered to another project”The domain is already claimed by a different SkySaver projectConfirm the domain with your team, or use a different domain for this project
A user isn’t redirected to the identity providerTheir email domain isn’t registered under SSOAdd their domain under the SSO tab
A previously-invited user’s first SSO login fails onceKnown one-time linking quirk for accounts invited before SSO was enabledHave them sign in again
New SSO user only has read-only accessThis is expected — first-time SSO sign-ins get read-only access by defaultInvite the user by email under Users before their first login to grant elevated permissions instead