SSO / SAML

What’s supported

Signalog supports SAML 2.0 for single sign-on. We’ve tested with:

• Okta
• Google Workspace (Cloud Identity)
• Microsoft Entra ID (Azure AD)
• Auth0
• OneLogin

Any SAML 2.0-compliant IdP should work. SCIM provisioning is on the roadmap but not yet available. For now, users are created on first SSO login (just-in-time provisioning).

SSO is a Business-tier feature.

Step 1: Get your Service Provider (SP) metadata

Signalog publishes SP metadata at a public URL per team:

https://your-domain/api/v1/teams/{teamId}/sso/metadata

The metadata is XML and includes:

• Entity ID (your team’s unique SP identifier)
• Assertion Consumer Service URL (where the IdP POSTs SAML responses)
• Public certificate (used by the IdP to encrypt assertions, optional)

Open Team Settings → SSO and you’ll see a copyable URL. Most IdPs accept “import metadata via URL”. Paste this in and they’ll auto-configure.

Step 2: Configure your IdP

The exact steps differ per IdP, but the high-level shape is:

1. Create a new SAML 2.0 application
2. Import Signalog’s SP metadata (URL above)
3. Set the NameID format to email (we identify users by email)
4. Configure attribute mappings:
   • email → user’s email
   • name → user’s full name (optional but recommended)
5. Assign the application to the users / groups who should have access
6. Save and download the IdP metadata XML

Okta example

1. Okta Admin → Applications → Browse App Catalog → Search “SAML 2.0” → Create
2. App settings:
   • Single sign-on URL: https://your-domain/api/v1/auth/sso/callback
   • Audience URI (SP Entity ID): the entity ID from Signalog’s metadata
   • Name ID format: EmailAddress
3. Attribute statements:
   • email → user.email
   • name → user.firstName + " " + user.lastName
4. Assign to users
5. View Setup Instructions → copy the IdP metadata URL or download XML

Google Workspace example

1. Google Admin → Apps → Web and mobile apps → Add custom SAML app
2. Download metadata
3. Service provider details:
   • ACS URL: https://your-domain/api/v1/auth/sso/callback
   • Entity ID: from Signalog’s metadata
   • Name ID format: EMAIL
4. Attribute mapping: email and name as above
5. User access: assign to the right OUs / groups

Step 3: Configure Signalog with the IdP metadata

Back in Signalog Team Settings → SSO:

1. Paste the IdP metadata URL or upload the IdP metadata XML
2. Optionally set a default role for users created via SSO (defaults to member)
3. Click Save

Signalog parses the IdP metadata and stores the entity ID, SSO URL, and signing certificate.

Step 4: Test with a non-enforced login

Before enforcing SSO, verify it works:

1. Open an incognito window
2. Navigate to https://your-domain/api/v1/auth/sso/{teamSlug} (the team slug is your team’s URL identifier)
3. You should be redirected to your IdP, then back to Signalog logged in

If something fails, the audit log captures SAML errors with detail. Common issues:

• NameID format mismatch: idP is sending NameID as unspecified, Signalog expects email
• Attribute missing. email claim isn’t present in the SAML response
• Certificate mismatch: idP signed with a different cert than the one in metadata

Step 5: Enforce SSO (optional, recommended)

Once SSO is verified, you can require it for all team members:

1. Team Settings → SSO → toggle Enforce SSO
2. Save

Enforcement effects:

• Members can no longer sign in with email/password. They must use SSO
• The login page detects the team and redirects to the IdP automatically
• Owner accounts can still use password login as a break-glass (so a misconfigured IdP doesn’t lock everyone out)

Just-in-time provisioning

When a user signs in via SSO for the first time:

1. Signalog matches them to an existing user by email
2. If no match, a new user is created with the email and name from SAML attributes
3. They’re added to the team with the configured default role
4. The audit log records user.sso.provisioned with the actor and source IdP

Removing access

To remove a user’s access:

1. Remove them from the SAML application in your IdP (recommended. It stops new logins)
2. Remove them from the team in Signalog (terminates their existing sessions)

If you only do step 1, existing Signalog sessions continue until they expire (default 24h for access tokens, 30d for refresh tokens). Doing both is safer.

Owner break-glass

Team owners can always sign in with password, even when SSO is enforced. This is intentional: if your IdP is misconfigured or temporarily down, an owner can still get into the team to fix things.

If you want to fully disable password login for owners (full SSO enforcement, no exceptions), open a support ticket. It’s available but requires explicit opt-in to avoid accidentally locking people out.

SCIM provisioning (roadmap)

True SCIM-based provisioning (auto-create, auto-deactivate, auto-update from your IdP) is on the roadmap. For now:

• Provisioning: just-in-time on first SSO login (good enough for most teams)
• Deactivation: manual in Signalog after removing IdP access (or via API)
• Updates: name changes propagate on next SSO login

If your compliance requirements need SCIM specifically, contact us.

Plan availability

SSO/SAML is Business-only. Other auth options:

Next steps

• Set up two-factor authentication. Even with SSO, 2FA on the IdP side is recommended
• Audit log. Auth events are most useful when paired with SSO
• Configure team members. Manage roles for SSO-provisioned users