Set Up Single Sign-On

With single sign-on (SSO) the members of a workspace sign in through your company's identity provider, for example Microsoft Entra ID, Google Workspace, Okta or Keycloak. ContentMate supports SAML 2.0 and OpenID Connect (OIDC). This article walks admins through the setup in ContentMate and at the provider. How members sign in is described in Sign In with Single Sign-On.

Requirements

• Plan: The workspace owner's plan is Agency. Otherwise the card Single Sign-On (SSO) in the workspace settings is locked.
• Role: You are an admin of the workspace. Custom roles cannot receive the permission to manage SSO.
• Recent sign-in: Every change to SSO needs a sign-in with your password within the last five minutes. If it is older, the card shows Sign in again with the button Sign in again with password.
• Identity provider: a provider that supports SAML 2.0 or OpenID Connect, and someone who may create an application there.

A workspace has at most one identity provider.

How signing in works

Signing in always starts at ContentMate: with Sign in with SSO on the sign-in page or through the workspace's sign-in link. ContentMate sends the person to the provider and accepts only answers that belong to this request. ContentMate refuses a sign-in that starts in the provider's portal (IdP-initiated). If a tile in your company's portal should lead to ContentMate, enter the sign-in link there. Whoever clicks the tile first sees a short confirmation page from ContentMate and reaches the sign-in with Continue to the identity provider.

You decide at the provider who gets access. Once a domain is proven, ContentMate creates an account for every person of this domain who can sign in to ContentMate at the provider. So assign the application at the provider only to the people or groups who should use the workspace.

Step 1: Copy the details for the identity provider

Open Settings in the workspace and the card Single Sign-On (SSO). Under Details for your identity provider you find four addresses with a copy button. They apply to this workspace only and stay the same, even when you set the provider up again.

Step 2: Create the application at the provider

Create an application for ContentMate at the provider and assign the people or groups who should sign in. Guides for the common providers follow further below. For every provider:

SAML 2.0

• The response and the assertion must be signed with the provider's certificate. Requests from ContentMate are not signed.
• ContentMate takes the NameID as the person's identifier. Best is a permanent identifier that never changes and is never reassigned (format persistent). An email address as NameID works too; if the address changes, though, the person counts as a new sign-in.
• The email address must be in one of these attributes: email, mail, emailAddress, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, urn:oid:0.9.2342.19200300.100.1.3 or urn:oid:1.2.840.113549.1.9.1. If the NameID itself is an address, that is enough.
• First and last name are optional: givenName, firstName or http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname, and sn, surname, lastName or http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname.

OpenID Connect

• Type: web application with a client secret (confidential client), authorization code flow. ContentMate uses PKCE and authenticates at the token endpoint with client ID and secret via HTTP Basic.
• Scopes: openid email profile.
• ContentMate reads the details only from the ID token, not from the UserInfo endpoint. So the address (email) must be in the ID token; first and last name (given_name, family_name) are optional.
• If the provider reports email_verified as false, ContentMate creates no account. If it does not send the claim, the address counts as confirmed.

Step 3: Enter the provider in ContentMate

Choose SAML 2.0 or OIDC / OpenID Connect under Protocol and fill in the fields.

SAML 2.0

OpenID Connect

Click Save. The card then shows Active. The protocol cannot be switched later: to do so, remove the provider and set it up again.

Step 4: Choose the default role

Under Default role you choose the role of people whose account is created at their first SSO sign-in. Choose the role with the fewest permissions that is enough for most of them, and grant more selectively in the member list. New accounts count towards the plan's member limit.

Step 5: Prove your domains

The identity provider creates new accounts only for addresses of proven domains, and the sign-in page finds the workspace only through a proven domain.

1. Enter your domain under Domains, such as example.com, and click Add domain.
2. ContentMate shows a TXT record with Name _contentmate-verification.example.com and a Value contentmate-verification=…. Create it in the domain's DNS.
3. Click Check. The domain then shows Proven.

DNS changes usually take minutes, but depending on your DNS provider's settings up to 72 hours. If the check reports that the record was not found, try again later. A domain always belongs to only one workspace. Leave the TXT record in place.

People who already have a ContentMate account do not need a proven domain: they link the provider themselves once in their profile.

Step 6: Test

Open the Sign-in link for members in a private browser window and sign in with a test account that is assigned to the application at the provider. A private window matters: a sign-in through the provider does not replace the session of another account, and you stay signed in with your password in your main window in case something is not right yet.

How accounts come about

A sign-in is bound to the identifier the provider sends (SAML: NameID, OIDC: sub) and opens only this workspace. Whoever is no longer a member of the workspace cannot get in through the provider either.

Important when offboarding: ContentMate does not sync users with the provider. Whoever is blocked at the provider can no longer sign in anew, but stays signed in in a running session until it ends: 24 hours after its last use, at the latest 14 days after signing in. So also remove people who leave from the workspace.

Enforce SSO

With Enforce SSO, members reach the workspace only through the identity provider. Their other workspaces stay reachable with their password. The owner keeps signing in with a password, so that a broken provider does not lock anyone out.

Switch it on only once the sign-in is tested and all members have linked their account or were created through the provider. If the owner's plan no longer includes SSO, it is not enforced.

Who may change what

Whatever the provider is trusted for, only the owner changes:

• switching on Enforce SSO,
• for SAML the entity ID, the login URL and the certificate,
• for OIDC the issuer URL and the client ID.

Whoever controls the trusted provider can sign in every linked member. That is why these fields are closed to other admins. The client secret, the default role and the domains can be changed by all admins.

Protection period for admins: If an admin removes another member who may manage members, or takes permissions away from them, the change waits 48 hours. The person concerned receives an email, and the owner can withdraw the change during this time. What the owner changes after signing in with a password applies immediately.

Renew the certificate

SAML certificates expire, depending on the provider after one to five years. ContentMate always trusts exactly one certificate of the provider. So the switch is a hard cut: between activating it at the provider and saving it in ContentMate, sign-ins through the provider fail. To keep the gap short:

1. Create the new certificate at the provider, but do not activate it yet.
2. The owner signs in to ContentMate with their password and keeps the SSO card open.
3. Activate the certificate at the provider at a quiet time and enter it in ContentMate right afterwards.

With OIDC the signing keys change automatically. Only the client secret expires and must be renewed in time.

Remove the provider

Remove provider unlinks every sign-in linked to this provider. Accounts the provider created have no password; these people set a new one with Forgot password? on the sign-in page. The memberships stay.

Guides per provider

The providers' interfaces change now and then; the labels below match their English interfaces as of October 2026. "Entity ID", "ACS URL", "Redirect URI" and "sign-in link" mean the details from step 1.

Microsoft Entra ID

SAML

1. In the Microsoft Entra admin center, open Entra ID → Enterprise apps → All applications → New application → Create your own application, enter a name, choose Integrate any other application you don't find in the gallery (Non-gallery) and click Create.
2. Open Single sign-on → SAML and, under Basic SAML Configuration, Edit. Enter: Identifier (Entity ID) = entity ID, Reply URL = ACS URL, Sign on URL = sign-in link. With the sign on URL the tile in My Apps starts through ContentMate; without it ContentMate would refuse the sign-in.
3. Under Attributes & Claims the default claims already fit (…/claims/emailaddress, …/givenname, …/surname). For Unique User Identifier (Name ID), set the format Persistent with the source user.objectid. If your accounts have no mail attribute, use the source user.userprincipalname for emailaddress, provided the UPN is the real address.
4. Under SAML Certificates, download the Certificate (Base64) and enter an address under Notification email; Entra then warns before it expires.
5. Under Set up …, copy the Login URL into the field Login URL and the Microsoft Entra Identifier (https://sts.windows.net/<tenant ID>/, with a trailing slash) into the field Entity ID in ContentMate. Paste the content of the certificate file under Certificate (X.509).
6. Under Properties, set Assignment required? to Yes and assign the people or groups under Users and groups.

OpenID Connect

1. Open Entra ID → App registrations → New registration, choose only your own tenant under Supported account types and enter the redirect URI as Redirect URI with the platform Web.
2. The overview shows the Application (client) ID (for Client ID) and the Directory (tenant) ID. The Issuer URL is https://login.microsoftonline.com/<Directory (tenant) ID>/v2.0, with the ID as a GUID, not your domain name.
3. Under Certificates & secrets → Client secrets, create a new secret and copy the Value, not the Secret ID. Entra shows it only once. Note the expiry date.
4. Under Token configuration → Add optional claim → ID, add the claims given_name and family_name. The address only comes for accounts that have an email address.
5. Under Enterprise apps → (your app) → Properties, set Assignment required? to Yes and assign people or groups.

Do not delete the app registration and do not create it anew: Entra then issues new identifiers, and all links are lost.

Google Workspace

SAML

1. As a super admin, open Apps → Web and mobile apps → Add app → Add custom SAML app in the Admin console and enter a name.
2. Under Google Identity Provider details you find the SSO URL (for Login URL), the Entity ID (for Entity ID) and the Certificate. Download or copy the certificate.
3. Under Service provider details, enter ACS URL = ACS URL and Entity ID = entity ID. Leave the Start URL empty. Keep Basic Information > Primary email as the Name ID.
4. Under Attribute mapping, map Primary email to the attribute email, First name to firstName and Last name to lastName.
5. Under User access, switch the app on for the matching organizational units or groups. This can take up to 24 hours.

Google sends the primary email address as the identifier. If an address is renamed or reassigned to another person, the link no longer fits; so always also remove people who leave from the workspace. Test with the sign-in link: the button Test SAML login and the tile in the app launcher start at Google and do not work with ContentMate.

OpenID Connect

1. Open a project of your organization in the Google Cloud console, fill in the details under Google Auth Platform → Branding and choose the user type Internal under Audience.
2. Under Clients → Create client, create a Web application and enter the redirect URI under Authorized redirect URIs.
3. Copy the client ID and client secret right away: Google shows the secret only when it is created.
4. The Issuer URL is https://accounts.google.com.

With OIDC every person in your organization can sign in; there is no assignment to individual people. Choose the default role carefully, or use SAML. Google deletes OAuth clients that have not been used for six months and announces this by email 30 days in advance.

Okta

SAML

1. In the Admin Console, open Applications → Applications → Create App Integration and choose SAML 2.0. Under General Settings, tick Do not display application icon to users; otherwise the tile would start at Okta.
2. Enter: Single sign-on URL = ACS URL (with Use this for Recipient URL and Destination URL), Audience URI (SP Entity ID) = entity ID, Name ID format Unspecified. As the Application username, a permanent identifier is best (Custom with user.getInternalProperty("id")); Email works too.
3. Under Attribute Statements, add: email = user.email, firstName = user.firstName, lastName = user.lastName.
4. Check that the response and the assertion are signed (Signed).
5. Under Sign On → View SAML setup instructions you find the Identity Provider Single Sign-On URL (for Login URL), the Identity Provider Issuer (for Entity ID) and the X.509 Certificate.
6. Assign people or groups under Assignments. For a tile, create a Bookmark App with the sign-in link.

OpenID Connect

1. Choose Create App Integration → OIDC – OpenID Connect → Web Application, grant type Authorization Code, and enter the redirect URI under Sign-in redirect URIs. Limit access to selected groups under Assignments.
2. Under General → Client Credentials you find the client ID and client secret.
3. The Issuer URL is your Okta domain, such as https://yourcompany.okta.com.

Depending on its settings, Okta's ID token contains only a few details and no email address. Since ContentMate reads the address from the ID token, no new accounts can be created then. Check the sign-in with a test account that has no ContentMate account; if the address is missing, use SAML with Okta. If an address is unconfirmed in Okta, ContentMate refuses the sign-in.

Keycloak

SAML

1. In the realm, create a client of type SAML under Clients → Create client. The Client ID must be exactly the entity ID.
2. Enter the ACS URL under Valid redirect URIs. Set Name ID format to persistent, leave Force POST binding and Sign documents on and switch on Sign assertions. Leave IDP-Initiated SSO URL name empty.
3. In the Keys tab, switch off Client signature required; requests from ContentMate are not signed.
4. Under Client scopes → (client)-dedicated → Add mapper → By configuration → User Property, create three mappers: property email with SAML Attribute Name email, and likewise firstName and lastName. The predefined mappers X500 email, X500 givenName and X500 surname work as well.
5. The Login URL is https://<host>/realms/<realm>/protocol/saml. The Entity ID and the certificate are in the descriptor at https://<host>/realms/<realm>/protocol/saml/descriptor; you also find the certificate under Realm settings → Keys in the RSA row.

OpenID Connect

1. Create a client of type OpenID Connect, switch on Client authentication, leave Standard flow on and enter the redirect URI under Valid redirect URIs.
2. The secret is in the Credentials tab. The Issuer URL is https://<host>/realms/<realm>.

In Keycloak every person of the realm can sign in to every client; you can restrict this only with a custom authentication flow. If Email verified is off for a person, ContentMate refuses their sign-in through OIDC. Rotating the realm keys changes the SAML certificate for all SAML clients.

Error messages during setup

Error messages when signing in are explained in Sign In with Single Sign-On.

Frequently asked questions

Can a workspace have several identity providers?

No, a workspace has at most one. Several domains are possible.

Does signing in from my provider's portal work?

Only through the sign-in link. ContentMate refuses a sign-in that starts at the provider, because it cannot be matched to a request.

Does ContentMate create or delete users automatically?

Accounts are created at the first SSO sign-in if the domain is proven. There is no sync with the provider, such as through SCIM: remove people from the workspace yourself.

Do members see their other workspaces through SSO?

No. A sign-in through the provider opens only that provider's workspace.

Related articles

• Sign In with Single Sign-On
• Workspace Settings
• Pricing & Subscription