This guide walks through the full setup for a private documentation site in Doxbrix. It explains when to use each reader sign-in method, how to configure it corr...
This guide walks through the full setup for a private documentation site in Doxbrix. It explains when to use each reader sign-in method, how to configure it corr...
This guide walks through the full setup for a private documentation site in Doxbrix. It explains when to use each reader sign-in method, how to configure it correctly, and how to validate that readers will see the right sign-in experience before you launch.
Who this is for
Teams publishing documentation that should not be openly accessible on the public internet, including:
- internal knowledge bases
- partner or customer documentation portals
- staging or pre-launch documentation sites
- product docs that should be limited to authenticated readers
What you will configure
In Doxbrix, reader access is controlled in two related layers:
- Reader mode and Preview access rule in Reader Access
- Reader authentication inside the same section
The first layer decides whether the site is public or private by default. The second layer decides how readers prove identity when the site is private.
Understand the available sign-in methods
The Reader authentication area offers these methods:
| Method | Best for |
|---|---|
| **Public** | Open sites with no sign-in requirement |
| **Password** | Small private sites where one shared password is acceptable |
| **Email domain** | Reader groups who should verify they belong to an approved company domain |
| **Workspace SSO** | Sites that should reuse an identity provider already configured at the workspace level |
| **Custom IdP** | Sites that need a dedicated identity provider just for this documentation property |
Choose the method based on the reader population, not just convenience. A method that is easy for admins can still be confusing or insecure for readers.
Step 1 — Make the site private
Open Project settings, then go to Reader Access.
In the Reader Access section, set Reader mode to Private. This tells Doxbrix that readers must be authenticated before they can access the site.
Decide who can open preview links before launch:
- Workspace members for broad internal review
- Project members for tighter pre-launch control
- Anyone with link only when you intentionally want open preview access
Step 2 — Choose the right sign-in method
Use the method cards in Reader authentication to pick how readers should authenticate.
Option A — Password
Use Password when:
- the site is private but the audience is small
- you need fast setup for a short-lived private site
- you do not need identity-level reporting for individual readers
Choose Password in Reader authentication.
Enter a site password and, if needed, a password hint for readers.
Check the effective-access banner and confirm that Doxbrix reports the saved sign-in method correctly before you save the page.
Option B — Email domain
Use Email domain when:
- readers belong to one or more known company domains
- you want lightweight identity verification without full SSO setup
- each reader should authenticate as an individual rather than with a shared secret
Typical examples:
- customer docs for users at
customer.com - partner documentation for approved reseller domains
- internal docs for multiple company domains after an acquisition
Choose Email domain in Reader authentication.
Enter the approved reader domains in the configuration area. Review the list carefully so only valid reader domains are allowed.
Review any email or verification-related behavior in the section so the reader journey matches your security expectations.
Option C — Workspace SSO
Use Workspace SSO when:
- your workspace already has an identity provider configured
- the docs site should inherit the same enterprise sign-in posture
- you want the reader experience tied to the broader workspace identity model
Choose Workspace SSO in Reader authentication.
Pick one of the identity providers already available at the workspace level. Doxbrix will block saving if no workspace identity provider is available or selected.
Confirm that the per-source checklist is fully satisfied before you save.
Option D — Custom IdP
Use Custom IdP when:
- the docs site needs its own dedicated identity provider
- the site should not inherit the workspace-wide provider
- a customer-facing or partner-facing site needs a separate sign-in system
Choose Custom IdP in Reader authentication.
Use the provider gallery to connect the identity provider for this project. This connection is activated immediately so you do not end up with a half-configured sign-in option that was never saved.
After the provider is connected, select it as the active sign-in method for this docs property.
Step 3 — Check the sign-in page details
The reader sign-in experience is not only about security. It is also part of the product experience. Review any visible sign-in text, support contact details, and reader guidance so the page is clear to people who are not familiar with your internal setup.
Ask:
- will the reader understand why access is restricted?
- does the sign-in method match what the audience expects?
- is there a support contact path if access fails?
Step 4 — Review Access diagnostics
After you configure the authentication method, stay in Reader Access and inspect Access diagnostics.
This area helps catch issues such as:
- incomplete sign-in method setup
- mismatches between private reader mode and reader authentication readiness
- policies that could send readers to the wrong login experience
Do not skip this step. It is the last practical check before you expose the site to real readers.
Step 5 — Test the reader journey before launch
Use a complete test pass before sharing the site:
Use an incognito or private window so your existing workspace session does not hide authentication problems.
Confirm that the reader sees the expected sign-in path, such as password, email-domain verification, or SSO.
Complete sign-in using a reader account or credential that should be allowed.
Also test a user or domain that should not be allowed so you can verify that the site fails closed instead of failing open.
Recommended patterns
Use these rules of thumb when choosing a method:
- use Password for temporary, low-complexity private sites
- use Email domain for lightweight authenticated reader groups
- use Workspace SSO for internal enterprise docs
- use Custom IdP for dedicated partner or customer access models