Set up SSO (SAML 2.0)
Single sign-on (SSO) lets your team authenticate through your organization's identity provider (IdP) instead of using email and password. Topicary supports SAML 2.0 with any compliant IdP, including Okta, Azure AD, Google Workspace, and OneLogin.
Before you begin
This feature requires the Enterprise capability tier (the Business ). During the beta, every project is on the free Solo tier, so this feature is locked by default: go to Settings ▸ Billing and request Enterprise access to unlock it.
Only project members with the Admin can configure this feature. Authors and Reviewers do not have access to these settings.
Configure your identity provider
Add Topicary as a new SAML application in your IdP. You will need these values:
Field | Value |
|---|---|
ACS URL (Assertion Consumer Service) |
|
Entity ID (Audience URI) |
|
Name ID format |
|
The Entity ID (audience) must match exactly, including the https:// scheme and the www. prefix. Topicary rejects any assertion whose audience differs. Set the Name ID to the user's email address; Topicary derives the account email from NameID.
Configure SSO in Topicary
Go to Settings in the sidebar.
Open the SSO tab.
Enter your IdP's Entity ID (also called Issuer URL).
Enter the SSO URL (the IdP's SAML endpoint where authentication requests are sent).
Paste the X.509 certificate provided by your IdP (used to verify SAML response signatures).
Configure the attribute mapping (see below).
Click Save.
Attribute mapping
Topicary extracts user information from the SAML assertion. The email always comes from the SAML `NameID` element. The SSO settings expose two configurable attribute fields:
Topicary field | Source | Configurable |
|---|---|---|
| No | |
Name | The SAML attribute named in the Name attribute field | Yes |
Set the Name attribute in the SSO settings to match your IdP's attribute name. For example, if your IdP sends displayName for the user's full name, enter displayName.
If your IdP also sends a role attribute, Topicary reads it and caps the result at author or reviewer (see Security details). When no role is provided, new users default to Author.
If the name attribute is not mapped or not provided in the SAML assertion, Topicary derives a display name from the email address.
Just-in-time provisioning
When SSO is enabled, Topicary automatically creates a project membership for any user who authenticates through your IdP for the first time. New users are assigned the Author role by default (or the role from your IdP's role attribute, capped at author or reviewer).
Provisioning happens automatically for anyone your IdP authenticates against this connection. To control exactly who can sign in, restrict the connection with Allowed email domains (below), and scope access at the IdP by assigning only the right people to the Topicary SAML application.
Restrict allowed email domains
The SSO settings include an optional Allowed email domains field, a comma-separated list of domains permitted to sign in through this connection (for example, acme.com, acme.io). When set, Topicary rejects any SAML assertion whose NameID email is outside the list.
Leave the field blank to accept any domain your IdP asserts. Restricting it to domains you own prevents a misconfigured or compromised IdP from vouching for outside identities.
Test the configuration
Click Test Connection in the SSO settings to validate your configuration before rolling it out. This check confirms that the IdP Entity ID is a valid URI and that the X.509 certificate parses correctly. It does not perform a full sign-in round trip.
To verify an end-to-end login, sign in through your IdP with a test account after saving the configuration.
Confirm sign-in works before rolling SSO out to your team. SSO-provisioned users are capped at the author or reviewer role, so keep at least one admin who signs in with email and password.
Security details
The SAML implementation includes the following protections:
XML Signature Wrapping (XSW) attack protection: Topicary rejects SAML responses containing multiple Assertions and verifies the Reference URI and digest to prevent signature wrapping attacks.
SHA-256 minimum: SHA-1 signature algorithms are rejected. Your IdP must use SHA-256 or stronger when signing SAML assertions.
Role ceiling for SSO-provisioned users: users provisioned through SSO (including JIT provisioning) are capped at the author or reviewer role. Admin access must be granted separately by a project administrator through Manage team members.
See also
Manage team members: invite users and assign roles
Security and data handling: X.509 certificate verification and authentication architecture
Plans and limits: SSO requires a Business plan