Single Sign-On (SSO) via SAML

Single Sign-On (SSO) using SAML 2.0 allows your organization to authenticate users through a centralized Identity Provider (IdP), while Tagd acts as the Service Provider (SP). Your identity provider stays in charge of authentication, including multi-factor authentication and conditional access, and Tagd never sees a password.

Prerequisite: An identity provider that supports SAML 2.0 (for example, Microsoft Entra ID (Azure AD), Okta, ADFS or Google Workspace).

Using OpenID Connect instead? See Single Sign-On (SSO) via OpenID Connect (OIDC).

Step 1: Collect Service Provider (SP) details

The following SAML SP details are required when configuring your Identity Provider:

Step 2: Configure your Identity Provider (IdP)

In your Identity Provider create an application,

1. Create a new SAML 2.0 application, for example named "Tagd"

2. Enter the Entity ID and Reply URL (ACS URL) provided above, and set the Name ID format to EmailAddress

3. Configure user attributes / claims to be included in the SAML response

   1. email (Mandatory)

   2. given_name (first name)

   3. family_name (last name)

   4. groups (Mandatory, minimum one group is required). Group names may only contain letters, digits and . - * _ (for example Acme-Legal, not Acme Legal)

4. Assign test users to both the SAML application and the group. A user who is not assigned cannot sign in

5. Choose a sign-out URL (Mandatory). Either your identity provider's sign-out endpoint, which also signs the user out of your identity provider, or a landing page such as your intranet. The URL must start with https://

6. Choose your preferred sign-in alias, for example "company". Your login link will be https://prod.tagd.ai/api/v1/auth/login?org=company. Use lowercase letters, digits and hyphens only

Step 3: Send SSO details to Tagd

Send the following details to [email protected]

• App Federation Metadata URL (preferred) or file (XML)

• Sign-out URL

• Preferred sign-in alias

• Test user email address

• Group names to sync, spelled exactly as they appear in the SAML response

• Attribute names, if they differ from email, given_name, family_name and groups

• Optional: a group that should grant the Tagd Administrator role

• Name and email of a technical contact for the go-live

Never send user passwords, private keys or identity provider API tokens. Once provided, SAML authentication will be configured by our team for your organization.

Step 4: Test the SSO setup

Before rolling out SSO to all users the setup is tested together with someone from our team.

• Open the login link and verify that it redirects straight to your identity provider

• Perform a test login using an IdP user account, including any multi-factor step

• Verify that the user's name and email appear correctly in Tagd

• Verify that the user is added to the mapped group in Tagd and has the expected role

• Verify that signing out ends the Tagd session and lands on your sign-out URL

• Verify that a user who is not assigned to the application cannot sign in

We strongly recommend testing with a limited group of users first. Report any issues to [email protected]

Step 5: GO-LIVE

Coordinate the go-live of the SSO integration in collaboration with your designated contact from our team:

• Decide on go-live date, and make sure your technical contact is reachable during the go-live.

• Assign users to the Tagd app in your identity provider. When a user signs in via SSO for the first time, their account will be automatically created or linked based on their email address. Group memberships from your identity provider add the user to the matching Tagd groups.

• Inform your users about the setup and share the login link. Users sign in with their corporate credentials and do not need a separate Tagd password.