How to Set Up SSO for a Self-Hosted Wiki: SAML, OIDC, and LDAP

TL;DR

• SSO lets you and your team sign in to your self-hosted wiki with your company accounts.
• If your team signs in through an identity provider (the service that holds your accounts), like Okta or Microsoft Entra ID, pick SAML or OIDC. If your accounts live in a directory like Active Directory, pick LDAP.
• In Docmost, you set up all three under Settings, Security & SSO, and you'll need the paid edition.
• Create your groups in the wiki first, using the same names you use in your identity provider, because group sync can only add people to groups that already exist.

Say your wiki started with 10 people and now has 200. Back then, adding someone was a quick job. Now it comes up all the time, and the worst part is the things that are easy to forget.

Now say someone leaves the company. Their email is shut off and their laptop is handed back, but their wiki login still works, because nobody remembered it was a separate account.

And then there's the everyday work. Every new hire needs an account and the right groups, so they can see the right spaces, and every team change means updating those groups. Your team has one more password to keep track of, and the reset requests can land on you. Then your security team may say everyone has to sign in to the wiki with their company login, or they won't approve it.

That's what single sign-on (SSO) is for. It takes sign-in off your plate by passing it to the system that already knows who works at your company. In this guide, you'll set it up on a self-hosted wiki with SAML, OIDC, or LDAP, using Docmost, an open-source wiki you can host yourself, as the example. Along the way, you'll sync groups, test everything before your team touches it, and learn what to check when sign-in fails.

What SSO Does for a Self-Hosted Wiki

SSO connects your wiki to an identity provider (IdP), which is just the service your company already uses to manage logins. Docmost works with providers such as Microsoft Entra ID, Okta, and Keycloak. Once the two are connected, you and your team can sign in to your wiki with your company accounts.

If you run the wiki, this saves you a lot of manual work. Your team doesn't need one more password for the wiki. With group sync on, people land in the matching wiki groups each time they sign in, as long as those groups already exist in your wiki. Since groups can be given access to spaces, access then follows your identity provider and you stop adding people one at a time. If you also turn on SCIM and enable user deactivation in your identity provider, switching someone's account off there deactivates their wiki account too.

If you're still choosing a platform, start with this guide to choosing self-hosted wiki software, or see how Docmost compares against the wiki you use now.

SAML vs OIDC vs LDAP: Which One Should You Use?

All three let your team sign in with their company accounts. They just connect in different ways and ask you for different details. In case you're wondering, SAML stands for Security Assertion Markup Language, OIDC for OpenID Connect, and LDAP for Lightweight Directory Access Protocol.

SAML and OIDC both rely on an identity provider, the service that holds your team's accounts, such as Okta, Microsoft Entra ID, or Keycloak. If you don't have one yet, you'll need one before you start. LDAP works without a separate identity provider, because your wiki checks sign-ins directly against your directory, like Active Directory. Your team still signs in with their company accounts either way.

Here's how to pick:

• Choose OIDC if that's what your identity provider or security team uses. You'll copy one URL out of the wiki and paste three values back in.
• Choose SAML if your provider or security team uses it, or if you run AD FS. You'll copy two values out of the wiki and paste back a login URL and your provider's certificate.
• Choose LDAP if your accounts live in Active Directory or another LDAP directory and you want the wiki to check sign-ins against it directly. Your team types their directory username and password into your wiki's sign-in page.

Before You Start: A Pre-Flight Checklist

Have these ready before you open any settings screen, so you don't have to stop halfway through:

• A paid edition license: To use SAML, OIDC, or LDAP in Docmost, you'll need the paid edition. SCIM needs the Enterprise plan.
• The right access on both sides: To create groups in the wiki, you need an Owner or Admin account. You'll also need admin rights in your identity provider, or someone beside you who has them.
• Your group list: Write down the groups you want to sync and the names your identity provider uses for them. You'll create matching groups in the wiki later.

How to Set Up SAML SSO

Step 1: Create the SAML Integration

In Docmost, go to Settings, then Security & SSO, and click Create SSO. Pick SAML from the dropdown, then give the integration a display name your team will recognize, like "Company SAML SSO." If you want the full reference, it's in the Docmost SAML documentation.

Step 2: Copy the Entity ID and ACS URL Into Your Provider

The setup window shows two values. The Entity ID is Docmost's unique identifier, and the Callback URL (ACS) is where your identity provider sends your team after they sign in. Create a new SAML app in your identity provider and paste both in. Every provider labels these fields a little differently. In Microsoft Entra ID, they're Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL). In Okta, they're Audience URI (SP Entity ID) and Single sign-on URL.

Step 3: Paste the IdP Login URL and Certificate

Once the app exists, your identity provider hands you two things to bring back. Paste its login URL into the IDP Login URL field. That's the page your team lands on when they sign in through SAML. Then paste the provider's public X.509 certificate text into IDP Certificate.

Step 4: Turn On Allow Signup and Enabled

Turn on Allow Signup if you want a wiki account created automatically the first time someone on your team signs in through SAML. Then turn on Enabled so the integration goes live, and click Save. Your SAML option now shows up on Docmost's sign-in page.

Using AD FS With Windows Sign-In

By default, Docmost asks AD FS for a password-based sign-in, which makes AD FS show its login form. If you want everyone on your intranet to sign in with Windows Integrated Authentication instead, set SAML_DISABLE_REQUESTED_AUTHN_CONTEXT=true on the server. Keep in mind that this setting covers every SAML provider on your Docmost server. You'll find it in the Docmost environment variables reference.

How to Set Up OIDC SSO

Step 1: Create the OIDC Integration

Go to Settings, then Security & SSO, click Create SSO, and choose OpenID (OIDC). Give it a display name like "Company SSO."

Step 2: Add the Callback URL to Your Provider

Copy the Callback URL from the setup window. Then, in your identity provider, create a new OIDC app and add that URL to its list of allowed redirect URIs. Copy it exactly as shown.

Step 3: Enter the Issuer URL, Client ID, and Client Secret

When you create the app, your identity provider gives you a Client ID and a Client Secret. Paste both into Docmost, along with your provider's Issuer URL. And treat that client secret like a password.

Step 4: Save and Check the Sign-In Page

Turn on Allow Signup if you want accounts created the first time someone signs in, turn on Enabled, and click Save. Your OIDC provider now shows up as a login option on your wiki's sign-in page. For every field in detail, see the Docmost OIDC documentation.

How to Set Up LDAP and Active Directory Sign-In

LDAP works a little differently from the other two. Instead of sending your team to a provider's sign-in page, your wiki checks their username and password against your directory itself. To set it up in Docmost, go to Settings, then Security & SSO, click create, and choose LDAP / Active Directory.

LDAP Settings Explained

Here's what each field means. DN stands for Distinguished Name.

Below those fields, you'll see three toggles. Group Sync copies directory group memberships into the wiki, Allow Signup creates accounts the first time someone signs in, and Enabled turns the connection on. If your directory supports it, use the ldaps:// address, because it encrypts the traffic between your wiki and your directory. Plain LDAP traffic to Active Directory isn't encrypted by default.

How the LDAP Sign-In Flow Works

When someone on your team picks the LDAP option and enters their username and password, here's what Docmost does:

1. It connects to your directory using the service account.
2. It searches for the person with your search filter.
3. It checks their password by trying to connect as them.
4. It reads their email, name, and groups.
5. It creates or updates their wiki account.
6. It syncs their group memberships, if group sync is on.

For every setting in detail, see the Docmost LDAP documentation.

Choosing a Search Filter

The search filter decides what your team types into the username box, and {{username}} stands in for whatever they enter. With (mail={{username}}), your team signs in with their email address. With (uid={{username}}), they use their directory username.

How to Sync Groups From Your Identity Provider

Create the Groups in the Wiki First

Group sync won't create groups for you. It only matches people to groups that already exist, so create each group in Docmost first, using the same name your identity provider sends. For SAML and OIDC, capital letters don't matter, so "engineering" and "Engineering" count as the same group. With SAML, your provider also has to send group names, not IDs.

So if your provider sends Engineering, Marketing, and HR-Team, create those three groups in your wiki, then turn on group sync in your SSO connection's settings. Only Owners and Admins can create groups, and the Docmost groups documentation walks you through it. Memberships update each time someone on your team signs in.

Once your groups are synced, you can limit wiki access by project.

Where Each Protocol Reads Groups From

Automatic Provisioning With SCIM

Group sync only runs when someone signs in. If you'd like your identity provider to set up accounts and groups ahead of time, and deactivate accounts when people leave, use SCIM. You'll need Docmost's Enterprise plan for it. With SCIM, your identity provider creates, updates, and deactivates users in your wiki, and it pushes groups and their members too. And unlike group sync, SCIM can create groups.

To turn it on in your wiki, go to Settings, then Security & SSO, and scroll to SCIM provisioning. Toggle Enable SCIM, copy the SCIM endpoint URL, and click Create SCIM token. Copy the token right away, because it's only shown once. Then, in your identity provider's provisioning settings, paste the endpoint URL and add the token as a bearer token. You can keep up to five tokens in your workspace.

Set up SSO before SCIM, because the people you add through SCIM still sign in through SSO. Also, while SCIM is on, it controls group membership, so SSO group sync is ignored. When your provider deactivates someone, your wiki deactivates their account but keeps their data. Every supported field is listed in the Docmost SCIM documentation.

How to Test Your SSO Setup

Test everything before you tell your whole company about the new sign-in option:

• Keep your admin session open in one browser window the whole time, so you can fix settings if sign-in fails.
• Open a private window and sign in with a non-admin test account through the new SSO option.
• Check that the account has the right name and email.
• Check that it landed in the right groups.
• Add the test account to another group in your identity provider, sign in again, and see whether your wiki picked up the change.

Troubleshooting Common SSO Problems

If sign-in isn't working, start with this table:

What Happens if You Turn LDAP Off?

If you switch LDAP off later, the people on your team who signed in through it keep their wiki accounts, but they'll need a password reset to get back in. Their group memberships also stay as they are until someone changes them.

Frequently Asked Questions

1. Do I need an identity provider to set up SSO on a self-hosted wiki?

For SAML and OIDC, yes. Both connect your wiki to an identity provider, which holds your team's accounts, such as Okta, Microsoft Entra ID, or Keycloak. LDAP works differently, because your wiki checks sign-ins directly against your directory, like Active Directory.

2. Should I use SAML or OIDC?

Use whichever your identity provider and security team already use. In Docmost, both are set up from the same screen. With OIDC, you copy one URL out of the wiki and paste three values back in. With SAML, you copy two values out and paste back a login URL and a certificate.

3. Do I have to create groups before syncing them?

Yes, for SAML, OIDC, and LDAP group sync. Those only match people to groups that already exist in your wiki. SCIM is different, because it can create groups for you.

4. What's the difference between SSO and SCIM?

SSO handles signing in. SCIM handles the accounts behind it. With SCIM, your identity provider can create, update, and deactivate users and groups in your wiki without waiting for anyone to sign in.

5. Is LDAP the same as SSO?

They're related, but not identical. SSO means your team signs in with one company account instead of a separate password for each tool. LDAP is one way to get there, because your wiki checks a person's username and password against your directory. With SAML and OIDC, your team signs in through your identity provider's page instead.

6. Can my existing users keep their accounts when I turn on LDAP?

Yes. Anyone on your team whose email address matches their directory entry gets linked to their LDAP account. The next time they sign in through LDAP, their profile updates with their directory details, and their groups sync if you've turned on group sync.

Set Up SSO on Your Self-Hosted Wiki With Docmost

You've now got what you need to connect your self-hosted wiki to your company login with SAML, OIDC, or LDAP. To try it on your own wiki, get a free trial license, or talk to the Docmost sales team about a paid edition license.