Single Sign-On (SSO)

Single Sign-On (SSO) allows your team members to authenticate with SetGet using your organization's existing identity provider (IdP). SetGet supports SAML 2.0 for SSO, which integrates with identity providers like Okta, Azure Active Directory, Google Workspace, OneLogin, PingIdentity, and others.

Why use SSO

Benefit	Description
Centralized authentication	Manage all user access from your IdP — one place for provisioning, deprovisioning, and policy enforcement
Reduced password fatigue	Users sign in with their corporate credentials; no separate SetGet password to remember
Stronger security	Leverage your IdP's security policies: MFA, conditional access, device trust
Automatic provisioning	New users are created in SetGet automatically on first SSO sign-in
Compliance	Meet enterprise audit requirements with centralized authentication logs

Prerequisites

Before configuring SSO, ensure you have:

• A SetGet workspace with an Owner or Admin role
• Access to your organization's SAML 2.0 identity provider admin console
• The ability to create a new SAML application in your IdP

SetGet SP metadata

SetGet acts as the SAML Service Provider (SP). You will need the following values when configuring the SAML application in your IdP:

Field	Value
Entity ID (SP Entity ID)	https://your-setget-domain.com/auth/saml/metadata
ACS URL (Assertion Consumer Service)	https://your-setget-domain.com/auth/saml/callback
SLO URL (Single Logout)	https://your-setget-domain.com/auth/saml/logout (optional)
Name ID format	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Binding	HTTP-POST

TIP

Replace your-setget-domain.com with your actual SetGet instance domain. If you are unsure of the exact URLs, check Workspace Settings > Security > SSO where the SP metadata values are displayed.

Identity provider setup

The exact steps vary by IdP, but the general process is:

Step 1: Create a SAML application

In your IdP admin console, create a new SAML 2.0 application. Common IdP instructions:

Identity Provider	Where to create
Okta	Applications > Create App Integration > SAML 2.0
Azure AD	Enterprise Applications > New Application > Create your own
Google Workspace	Apps > Web and mobile apps > Add app > Add custom SAML app
OneLogin	Applications > Add App > SAML Custom Connector
PingIdentity	Connections > Applications > Add Application

Step 2: Configure SAML settings

Enter the SetGet SP metadata values from the table above:

1. Set the ACS URL (also called Reply URL or Single Sign-On URL).
2. Set the Entity ID (also called Audience URI or Identifier).
3. Set the Name ID format to Email.
4. Set the Binding to HTTP-POST.

Step 3: Configure attribute mapping

SetGet expects the following SAML attributes in the assertion:

SAML attribute	Maps to	Required
email or NameID	User email address	Yes
first_name or givenName	User first name	Recommended
last_name or surname	User last name	Recommended
display_name	User display name	Optional (falls back to first + last)

WARNING

The email attribute (or NameID with email format) is mandatory. Without it, SetGet cannot identify the user. Ensure your IdP sends the email in the SAML assertion.

Step 4: Download IdP metadata

From your IdP, download or copy the following:

Item	Description
IdP Entity ID	The unique identifier for your identity provider
SSO URL	The URL where SetGet sends SAML authentication requests
Certificate	The X.509 certificate used to verify SAML assertion signatures
Metadata XML (optional)	A single XML file containing all of the above

Configure SSO in SetGet

1. Sign in to SetGet as a workspace Owner or Admin.
2. Navigate to Workspace Settings > Security > SSO.
3. Click Configure SSO or Edit SSO Configuration.
4. Enter the IdP details:

Field	What to enter
IdP Entity ID	The entity ID from your IdP
SSO URL	The single sign-on URL from your IdP
Certificate	Paste the X.509 certificate (PEM format)
Metadata XML	Alternatively, upload or paste the metadata XML to auto-fill all fields

5. Click Save Configuration.
6. Click Test SSO to verify the connection.

The test initiates a SAML flow in a new browser tab. If successful, you see a confirmation message with the authenticated user's attributes.

WARNING

Always test SSO before enforcing it. If SSO is misconfigured and enforced, workspace members (including admins) may be locked out.

Attribute mapping

After saving the base configuration, verify that attribute mapping is correct:

1. In the SSO settings, click Attribute Mapping.
2. Review the mappings:

SetGet field	Expected SAML attribute	Fallback
Email	email, NameID	None (required)
Display name	display_name, displayName	Constructed from first + last name
First name	first_name, givenName	Extracted from display name
Last name	last_name, surname, sn	Extracted from display name

3. If your IdP uses different attribute names, update the mappings to match.
4. Click Save.

SSO enforcement

By default, SSO is available as an optional sign-in method alongside email/password and OAuth. You can enforce SSO to require all members to authenticate through the IdP:

Enable enforcement

1. Navigate to Workspace Settings > Security > SSO.
2. Toggle Enforce SSO to on.
3. Confirm the action.

Enforcement behavior

Scenario	Behavior with enforcement
Existing member signs in	Redirected to IdP; email/password form is hidden
New user visits sign-in page	Only SSO option is shown
Password reset request	Disabled (passwords are not used)
OAuth sign-in	Disabled (only SSO is allowed)
Magic link sign-in	Disabled (only SSO is allowed)
API token authentication	Still allowed (tokens bypass SSO)

WARNING

Before enforcing SSO, ensure that at least one workspace owner can successfully authenticate through the IdP. If SSO is misconfigured after enforcement, contact your instance administrator to disable enforcement at the server level.

Emergency access

If SSO enforcement locks out all admins:

1. An instance administrator can access the admin panel directly.
2. Navigate to the workspace SSO settings in the admin panel.
3. Disable SSO enforcement.
4. Fix the SSO configuration and re-enable enforcement.

SSO + local authentication coexistence

When SSO is not enforced, both SSO and local authentication methods work simultaneously:

Sign-in method	Available
Email + password	Yes
Magic link	Yes
OAuth (Google, GitHub, etc.)	Yes (if configured)
SSO (SAML)	Yes

Users can choose their preferred method. If a user signs in via SSO for the first time and an account with the same email already exists (created via email/password), the accounts are linked automatically.

Account linking

Scenario	Behavior
New email via SSO	New account created automatically
Existing email via SSO	Existing account linked to SSO identity
SSO user tries email/password	Allowed (if enforcement is off)
Email/password user tries SSO	Allowed; accounts are merged

Just-in-time provisioning

When a user authenticates via SSO for the first time and does not have an existing SetGet account, SetGet automatically creates an account for them. This is called just-in-time (JIT) provisioning:

• The user's email, name, and display name are populated from the SAML assertion.
• The user is added to the workspace with the Member role by default.
• No manual invitation is required.

To assign specific roles automatically, see Group Sync.

Troubleshooting

Issue	Likely cause	Resolution
"Invalid SAML response" error	Certificate mismatch	Re-download the IdP certificate and update it in SetGet
User attributes are missing	Attribute mapping incorrect	Verify attribute names in IdP match SetGet expectations
SSO loop (redirects back to IdP)	ACS URL misconfigured	Verify the ACS URL in your IdP matches exactly
User created without name	Name attributes not sent	Add first_name and last_name to IdP attribute release
Locked out after enforcement	SSO misconfigured	Use instance admin panel to disable enforcement

Related pages

• Security Overview — authentication and authorization overview
• Group Sync — map IdP groups to workspace roles
• MFA — multi-factor authentication
• OAuth Providers — third-party authentication
• Session Management — manage active sessions