Why a shared wiki needs page-level access control for sensitive content
When HR, legal or security pages sit in the same wiki as general onboarding and engineering documentation, the wiki must enforce different read rules for each, and the platform choice comes after the identity design, not before it. Any of BookStack, XWiki or Outline can hold restricted pages, but each handles page-level restriction, group mapping and sign-in differently, so start by deciding which people and groups must read which content and where that membership is authoritative. A wiki that takes group membership from a directory through LDAP, SAML or OIDC inherits joiner, mover and leaver changes automatically. A wiki with local accounts does not, and that gap is where former staff keep reading salary bands or incident reports.
Space-level permissions alone are often not enough. A space is a convenient container, but a single HR space usually contains a few pages that only the HR business partner should open, such as investigations or compensation reviews, next to templates everyone needs. Page-level restrictions, or a separate space for the most sensitive material, let you separate those cases without duplicating content. Before go-live, confirm in the version you intend to run whether restrictions can be inherited from a book or space, whether a page can be locked to a named group, and whether attachments and page history follow the page's restriction. Test these with a non-administrative account, because administrators usually bypass the rules you are trying to check.
Outline needs a separate check. Its Business Source License 1.1 includes an additional use grant that forbids using the software to offer a commercial Document Service, so an organization that plans to run the wiki for customers or affiliates as a hosted service should review the Outline license terms with counsel before choosing it. For an internal wiki used by your own staff, that restriction is usually not the deciding factor, but it should be written down in the platform decision. Whichever platform you choose, ask the implementation partner to document which group-to-page mappings exist, who approves changes to them, and how a periodic review of restricted pages is recorded.
Which requirements shape SSO and page permissions
This table maps each requirement that governs a shared wiki holding HR, legal or security pages to its source and to what it means for the build. Read each row as a question to answer in your design: which requirement applies, what evidence an assessor will ask for, and which configuration choice it forces.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| Audit controls (45 CFR 164.312(b)) | Mechanisms that record and examine activity in systems holding ePHI, if the wiki holds ePHI or links to it | Enable and retain page view, edit and permission-change logs, and send them to a central log store; confirm which events your chosen wiki records natively |
| Transmission protection (45 CFR 164.312(e)(1)) | Guard against unauthorized access to ePHI sent over electronic networks | Enforce TLS on the wiki, the identity provider and the directory connection; confirm LDAP uses LDAPS or StartTLS and SAML or OIDC metadata is validated |
| Record retention (17 CFR 240.17a-4) | Preserve communications relating to the business for at least three years, where the wiki stores or links such communications | Confirm with counsel whether wiki pages or comments count as records; if they do, plan versioned retention outside normal page deletion |
| Role-based read rights | Readers see only the pages their role allows, including on search results and attachments | Map directory groups to wiki roles, set read rights at the space or shelf level, and test search and attachment access as a non-privileged user |
| Inherited versus overridden permissions | Clear rules for which permission wins when a space default and a page-level exception conflict | Document the default for each space, limit page-level overrides to named exceptions, and review overrides in each access review |
| Offboarding removal | Access ends when a person leaves or changes role, without relying on manual wiki clean-up | Drive removal from the directory group so deprovisioning takes effect at sign-in; check whether local wiki accounts and API tokens also need revoking |
| Periodic access reviews | Owners confirm that each reader of sensitive content still needs access | Export effective permissions per sensitive space, assign a named owner per space and keep signed review records |
| Group mapping integrity | Directory groups map predictably to wiki roles, without nested or stale groups granting unintended reads | Choose the attribute used for group membership, test nested group behavior, and alert when a mapped group is empty or renamed |
How LDAP, SAML and OIDC each map directory groups to wiki roles
LDAP is the protocol most often used for directory-backed sign-in in self-hosted wikis. BookStack documents LDAP as one of its primary third-party authentication options, so the wiki authenticates users against the directory and then uses the directory's group membership to decide what those users can see. The group data itself lives in the directory, so the wiki only reflects what the directory reports at sign-in or sync time.
- Group lookup: Confirm whether the wiki reads group membership from the user's record or queries a group object, and whether it resolves nested groups. Nested group support varies, so test it with a real nested example before relying on it.
- Search base and filters: Scope the user and group search bases narrowly so that service accounts, disabled users and contractor OUs do not inherit wiki access.
- Bind account: Use a dedicated, read-only bind account with a documented rotation process, not a personal administrator account.
- Stale membership: Membership changes are only applied when the wiki refreshes its view of the directory. Decide how often that happens and how quickly a removed user loses access to restricted pages.
- Group renames: If a group's distinguished name or common name changes, the mapping breaks silently. Store mappings against a stable identifier where the product allows it.
Confirm each attribute and mapping option against the BookStack third-party authentication documentation for your version before you configure it, and test removal of a user from a restricted group end to end.
SAML 2.0 is a browser-based federation protocol in which an identity provider asserts who a user is and, optionally, which groups they belong to. BookStack documents SAML 2.0 as a supported sign-in option, and the group claims in the assertion are what the wiki can map to roles. The wiki never queries the directory directly, so the identity provider decides what gets sent.
- Assertion attributes: Agree with the identity provider team on the exact attribute name and format for group claims, and confirm which product fields the wiki reads for role mapping.
- Claim scope: Filter the groups sent to the wiki so that only groups used for wiki access are included. Sending every group creates unnecessary exposure and mapping clutter.
- Metadata and certificates: Plan certificate rotation and metadata refresh as a recurring task, because an expired signing certificate blocks sign-in for every user.
- Session behavior: SAML assertions reflect group membership at login. A user who keeps an existing session may retain access to restricted pages until that session ends, so set session lifetimes deliberately.
- Group name changes: A renamed group in the identity provider changes the claim value, which can silently drop a user out of a role. Map to stable group identifiers where the identity provider offers them.
Confirm the attribute mapping and certificate handling with the BookStack SAML documentation and your identity provider's SAML guidance, then test a restricted-group user before and after a group change.
OpenID Connect is an identity layer on top of OAuth 2.0. BookStack documents OIDC as a primary sign-in option. For XWiki, the xwiki-contrib OpenID Connect extension can authenticate users against an external OIDC provider, and it can also make XWiki act as a provider. Group claims in the ID token or user info response are the usual source for role mapping, but the exact claim name and mapping behavior depend on the product and the provider.
- Claim configuration: Identify the claim that carries group data at your provider, such as a groups claim, and confirm whether the wiki reads it from the ID token or the user info endpoint.
- Scopes: Request only the scopes needed for group data, and confirm that the provider releases the group claim to this client.
- Token lifetime: Access and ID token lifetimes control how quickly a change in group membership reaches the wiki. Shorter lifetimes reduce stale access but increase sign-in traffic.
- Client secret and redirect URIs: Register exact redirect URIs and rotate client secrets through a managed process.
- Keycloak as a broker: Where the directory is not Active Directory or Entra ID, Keycloak can federate the directory and present a single OIDC or SAML client to the wiki. Keycloak supports user federation and identity brokering, which keeps mapping logic in one place.
Confirm claim names, token lifetimes and extension compatibility with the xwiki-contrib OIDC project and BookStack's documentation for your versions, and test group changes with a restricted-space user.
Which wiki platforms handle sensitive page permissions best
When HR, legal or security pages live in the same wiki as general company content, the platform has to support page-level restriction, directory-driven access and an audit trail. The four options below differ in how they authenticate users, which access features are free and which sit behind a paid edition, and where an external identity layer such as Keycloak fits in.
BookStack for role-based restricted pages
BookStack is MIT licensed and supports LDAP, SAML 2.0 and OpenID Connect sign-in, with a full role and permission system. Its content hierarchy of books, chapters and pages lets you isolate a restricted book for HR or legal from general spaces. Multi-factor authentication can be enforced per role, which is useful for security or finance editors. Check that page-level restrictions are set with the granularity you need, and test them with a user from each group before rollout. Official installation scripts cover Ubuntu releases, while Docker setups come from community projects, so confirm your support model.
XWiki Standard for open structured spaces
XWiki Standard is the free open source edition, licensed under LGPL 2.1, and its official Docker images run on Tomcat with MySQL, PostgreSQL or MariaDB. Its rights model can restrict spaces and pages, which suits organizations that need structured access by department. Directory integration is the gap to plan for: Active Directory and Azure AD SSO applications are listed as part of XWiki Pro, so the Standard edition needs an OpenID Connect extension or another route. Confirm which connector your directory requires before choosing this path.
XWiki Pro for directory-based SSO
XWiki Pro adds Active Directory and Azure Active Directory SSO applications, along with Office365 and OnlyOffice connectors and support from XWiki SAS. Pro and support subscriptions are sold in tiers by user count, and XWiki SAS states that cloud and on-premises pricing is the same. Ask the vendor whether the SSO application covers your group mapping rules, nested groups and offboarding behavior. If your identity provider is Okta, Google or a non-Microsoft LDAP, confirm support in writing before assuming the Pro application applies.
Outline with license limits
Outline is licensed under the Business Source License 1.1, and its additional use grant forbids using it to offer a commercial Document Service. An internal company wiki is a different use from offering a document service to third parties, but legal teams should read the license text before deployment. Confirm which SSO protocols the version you plan to run supports, and whether group-based access to individual collections meets your restriction model. Outline 1.11.0 is the release current at the time of research, so verify the version during your evaluation.
Keycloak as the identity layer
Keycloak is Apache 2.0 licensed and supports OpenID Connect, OAuth 2.0 and SAML 2.0, so it can sit in front of BookStack, XWiki or Outline and map directory groups to wiki roles. Its user federation and identity brokering let one login cover several applications. Production use requires a supported database, a high availability design with synchronous database replication, and a plan for operator upgrades in manual approval mode. Confirm how group claims reach each wiki before you assume the attribute mapping works end to end.
Which features need XWiki Pro and which do not
Before you buy anything, separate what XWiki Standard already gives you from what XWiki Pro adds. XWiki Standard is the free open source version, and it carries the page and space permission model that handles HR, legal or security spaces. XWiki Pro, from XWiki SAS, combines XWiki with business applications, connectors and support. For this topic, the Pro features that matter are the Active Directory and Azure Active Directory SSO applications, which XWiki Pro lists explicitly, and the Office365 and OnlyOffice connectors. If your requirement is only to restrict sensitive spaces to named groups, you may not need Pro at all. Confirm that against your own permission design first, because group-based restriction is a configuration question, not a licensing one.
XWiki Pro is sold in four tiers: Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users). XWiki SAS states that cloud and on-premises pricing is the same, so the hosting choice should be made on architecture and data residency grounds rather than price. Ask XWiki SAS for the current price of the tier that matches your headcount and for what the subscription includes in writing. Check whether the Active Directory SSO application is included in your chosen tier, and whether support covers the on-premises deployment you plan to run.
Before committing, confirm which SSO path you need. If your directory is Active Directory or Azure Active Directory and you want the vendor-supported application, XWiki Pro is the direct route. If you need OpenID Connect against another identity provider, the open source xwiki-contrib/oidc extension may cover the requirement without a Pro subscription. Check it against your needs: supported provider features, group claim mapping for restricted spaces, session behavior and who maintains the extension after installation. Compare both paths with your security team and your identity provider owner, and document the chosen path before the license decision is made.
How to roll out restricted spaces without exposing content during migration
This sequence moves HR, legal and security pages into restricted spaces in a controlled order, so that no sensitive page becomes readable by the wider company before its permissions have been tested and signed off. Each phase produces a document or record that the next phase depends on.
Classify content and assign owners
Inventory every space and page that holds sensitive material, such as HR case notes, legal holds, incident reports and privileged security findings, and tag each with a sensitivity level. Ask the business owner of each category to name an accountable approver for who may read and who may edit. The output is a classification register with one named owner per space. The step is complete when every space in the current wiki appears in the register and no space lacks an owner.
Design the group model and permission matrix
Translate the classification into directory groups and a matrix that maps each group to spaces, books or pages, with read, edit and manage rights. Decide whether restricted content lives in its own space or in restricted pages inside a shared space, because the choice changes how inheritance behaves. Confirm with the wiki vendor how page-level and space-level rules interact, and test that behavior in a scratch instance rather than assuming it. The output is a signed permission matrix that the content owners approve.
Configure the identity integration in a test instance
Connect the test wiki to the directory through LDAP, SAML 2.0 or OpenID Connect, depending on what your identity provider supports, and map directory groups to wiki roles. Use a copy of the group structure rather than production groups, and confirm which features need a paid edition, such as Active Directory SSO applications in XWiki Pro. Test sign-in with users from each group, including a user who should see nothing restricted. The output is a test report showing each group's visible spaces, with screenshots or exports attached.
Migrate or create restricted spaces in staging
Create the restricted spaces with the permissions locked before any content is imported, so that no page is ever visible under default settings. If you migrate from another wiki, import into staging first, check that permissions and group membership carried over, and confirm whether page history and attachment history are preserved by the tool you use. Remove or re-permission any content that arrived with broader rights than the matrix allows. The output is a staging inventory that matches the classification register page for page.
Run an access review against the matrix
Have each content owner and a security reviewer check the staging wiki against the approved matrix, using test accounts for each group and the wiki's own permission reports where available. Record every discrepancy, its cause and its fix, then re-test the affected pages. Keep the signed review record with the matrix version it tested. The step is complete when the reviewer signs off with zero open discrepancies or with each exception accepted in writing by the owner.
Cut over to production and lock the group map
Schedule the production change in a window agreed with the content owners, import or move the approved restricted spaces, and enable the directory integration for production users. Freeze the group map so that membership changes follow the directory process rather than manual wiki edits. Confirm the first production sign-in for each group and check that restricted spaces are hidden from users outside them. The output is a signed-off group map and a cutover record that names the matrix version live at the time.
Schedule recurring access reviews
Set a recurring review of group membership and restricted spaces, with the owner of each space as the reviewer, and define what triggers an ad hoc review, such as a team reorganization or an investigation. Include the wiki's audit logs in each review so that reviewers can see who viewed or changed sensitive pages. Keep each review record with the matrix version and the membership snapshot it covered. The process is working when the records for each cycle exist and each exception has a closed action.
What auditors ask for to prove who can read sensitive pages
This table lists the evidence an independent auditor typically asks for when sensitive wiki pages are restricted, and which system produces each item. Read each row as an input the auditor will test, not a conclusion, since DeployOpen prepares these records but does not issue audit reports or attestations. The main takeaway is that a permission matrix alone is weak evidence unless it is backed by identity group snapshots, configuration records and logs that show changes over time.
| Evidence item | Produced by | What the auditor tests |
|---|---|---|
| Current permission matrix export | Wiki (BookStack or XWiki) via its admin or API export | Which groups and users hold read, edit and manage rights on HR, legal and security spaces and pages, and whether inheritance is intended |
| Identity provider group membership snapshots | Identity provider (for example Keycloak or Active Directory) as a dated export | That the directory groups mapped to wiki roles match approved membership lists on the snapshot date |
| SSO and MFA configuration records | Identity provider and wiki configuration, kept under change control | That OIDC, SAML or LDAP sign-in is the only login path for sensitive spaces and that MFA enforcement settings match the documented policy |
| Audit log extracts of page views and permission changes | Wiki activity log, forwarded to the SIEM for retention | Who viewed or changed restricted content, and whether permission changes were made by authorized administrators |
| Keycloak authentication and admin event logs | Keycloak event and admin event logging, if Keycloak is the identity provider | Successful and failed sign-ins to the wiki and changes to clients, group mappings and realm settings |
| Offboarding removal records | Identity provider deprovisioning log plus wiki session and access checks | That leavers and transferred staff lost access to restricted spaces within the period the organization's own procedure sets |
| Periodic access review sign-offs | Document owner and reviewer, recorded in the wiki or GRC tool | That named owners reviewed each restricted space, approved or removed members, and kept the signed record |
| Central retention of wiki and identity logs | SIEM or log store receiving wiki and identity provider events | That logs are complete, time-synchronized and protected from edits by the administrators they record |
How much effort does restricted-page SSO take and what must we provide
What drives the cost of setting up SSO and page permissions for sensitive content?
The cost depends mostly on how complex the identity integration is and how much cleanup the group model needs. Connecting a wiki to LDAP, SAML or OIDC is one part of the work. Mapping directory groups to wiki spaces, pages and roles, and removing stale or overly broad groups, is usually the larger part. Other cost components are the number of spaces and pages with restricted content, the migration volume if content comes from Confluence or Notion, and any licenses. If you use XWiki, XWiki Pro or a support subscription is a recurring cost. XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan. Ask any partner for a quote that separates one-time integration and migration work from recurring licensing, hosting and support.
How long does restricted-page SSO take to implement?
The duration depends on the scope, so no fixed timeline applies to every organization. The main variables are the number of directory systems involved, how many groups need to be mapped, whether HR, legal and security spaces need separate approval workflows, and how much content must be migrated and checked. A written quote should state the phases, deliverables, dependencies on your teams and the acceptance criteria for each phase. Ask for the timeline to be tied to those deliverables, not to a generic estimate.
What must our team provide before a restricted-page SSO project starts?
Three groups of people need to be available. Directory administrators own the LDAP, Active Directory, SAML or OIDC configuration and can confirm attribute names, group structure and test accounts. Group owners confirm who should belong to each group, such as HR, legal or security staff, and approve removals. Content owners for each sensitive space decide who should read, edit and administer pages, and they sign off on the permission model before it goes live. Also plan for a named security or compliance contact who reviews the audit approach. Without these people in place, most delays come from waiting for decisions rather than from technical work.
Can our internal team set up SSO and page permissions without an implementation partner?
Yes, if your team has directory administration skills, experience with the chosen wiki's authentication settings, and the time to test and document the results. BookStack documents LDAP, SAML 2.0 and OpenID Connect sign-in, and it offers a role and permission system, so a capable internal team can often handle smaller scopes. Keycloak can act as the identity layer for several applications, which adds configuration work for realms, clients and brokering. Where the environment has many groups, sensitive spaces, audit requirements or a migration, a partner can take on the design and testing so that your team keeps ownership of decisions. DeployOpen implements and integrates self-hosted platforms inside your environment under a written, fixed scope.
Can Confluence permissions and page history move to the new wiki?
Confluence Migrator Pro from XWiki SAS migrates spaces, pages, users, groups, permissions, attachments and metadata, and it keeps page history but not attachment history. It is priced from 2000 EUR according to XWiki Store, and its trial is limited to 30 pages per migration. Before you rely on it, confirm with the vendor how each restricted Confluence space maps to XWiki spaces and rights, and test a sample of sensitive pages to confirm that readers and editors match the source. Attachment history will need a separate decision, such as archiving the source export.
What should we verify in a restricted-page SSO test before go-live?
Test with real accounts from each relevant group, plus users who should be denied access. Check that group membership changes in the directory reach the wiki, that a removed user loses access to restricted pages, and that administrators of the wiki cannot silently read content they are not meant to see. Confirm which roles can export, share or restore pages, because those actions can bypass the intended view. Record the test results and the group-to-role mapping as evidence, and schedule a recurring review of who can read each sensitive space.
Questions to put to an implementation partner before you sign
Start with how directory groups become wiki permissions, because that mapping decides who can read HR, legal and security pages. Ask the partner which group attributes they will map through LDAP, SAML or OIDC claims, and whether group membership is pulled at each sign-in or cached. Ask how nested groups are flattened, since a group nested inside an HR group can quietly grant access that nobody reviewed. Then ask how stale membership is handled: how quickly a leaver loses access, whether existing sessions and API tokens are revoked, and what happens when a directory is unreachable. Get the answers in writing for the specific tool you are considering, because BookStack and XWiki expose group and role mapping differently and the Pro applications change what is available in XWiki.
Ask for a restricted-page test plan before go-live, not a statement that permissions work. A credible plan creates a sensitive space, signs in as a user outside the membership list, and confirms the page, its attachments, its search snippets, its history and its exports are all unreadable. It should repeat the test through the API and for users who hold broad roles elsewhere. Ask how the partner proves this on the production configuration, and whether the results are kept as evidence for your access reviews. On the identity side, ask how a Keycloak deployment will be made highly available, which production database it will use from the supported list, and whether the database is synchronously replicated, since that is a stated requirement for the supported Keycloak designs. Ask how audit logs from both the wiki and Keycloak are retained, where they are exported, and who can alter them.
Finally, ask how upgrades will be applied and who approves them. For the Keycloak Operator, confirm the partner will use manual approval mode, which the project strongly recommends to avoid unintended upgrades. Ask how schema migration is handled: automatic at startup by default, or applied manually as SQL for larger deployments, and who reviews that SQL before it runs. Ask for the rollback procedure, the test environment that receives each release first, and how the partner keeps the wiki and identity versions in step. Confirm which support and consulting terms apply after handover, and what is covered by a retainer. Ask for a written scope that names each of these items, because open-source releases move quickly and the answers should be tied to the versions you approve.
How DeployOpen scopes and delivers restricted-access wikis
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For knowledge base SSO and page permissions for sensitive content, the work starts with a written scope that separates HR, legal and security content from general pages, then moves through identity integration, permission design, testing and a documented handover.
How we scope
- Inventory which HR, legal and security spaces must be restricted and who owns each one.
- Map existing directory groups to wiki roles and record which groups need read, edit or administer rights.
- Confirm which wiki platform and edition fit the feature list, including whether XWiki Pro features are required.
- Agree the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope.
How we build
- Configure SSO against your existing LDAP, SAML or OpenID Connect identity source inside your environment.
- Build the space and page permission structure, with group-based rules and explicit denials for sensitive spaces.
- Test sign-in, group mapping and access boundaries with named test accounts from each role.
- Harden the hosting, database, backups and admin access, and document each setting for later review.
How we hand over
- Provide a permission matrix and configuration record showing which groups can read or change each restricted space.
- Deliver an audit procedure that shows how to list who can read a given page and how to review changes over time.
- Run a handover session with administrators covering group changes, onboarding, offboarding and emergency access.
- Document upgrade, backup and restore steps so your team can operate the wiki after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Re-run access reviews after directory changes, reorganizations or new restricted spaces are added.
- Review platform releases and security updates, and plan upgrades in a staging environment before production.
- Ask any partner to confirm in writing which permission and audit features your chosen edition supports.
