A wiki's permission model determines who can read, edit, delete, and administer. Different models suit different organizations.
This page covers the major models and the patterns for managing access well.
Users have roles: viewer, editor, admin. Roles have permissions.
Viewer: read all
Editor: read all + edit
Admin: read all + edit + admin
Simple. Works for small organizations or where everyone has similar access needs.
Users belong to groups. Groups have permissions on specific resources.
Group "Engineering": read /engineering, edit /engineering
Group "Finance": read /finance, edit /finance
For organizations with departmental boundaries.
Per-resource access control list. Each page (or section) has its own ACL.
Page X: alice can edit; bob can read; engineering group can read
Most flexible; most overhead. For wikis with sensitive content.
Anyone can read; specific users can edit.
For open wikis (Wikipedia-style); some internal "transparency" cultures.
The standard set:
Different wikis combine these differently. Check what your platform supports.
Public wikis: default allow (everyone reads; few restrictions). Corporate wikis: default deny (start restricted; grant explicitly).
Page inherits parent permissions unless overridden. Reduces ACL bloat.
For Confluence-style hierarchical wikis, this is essential.
Roles within groups: "engineering admin" has admin within /engineering only.
For larger organizations.
Grant access for a specific period. Auto-expires.
For contractor access; temporary collaboration.
Allow group X; deny user Y (who's in group X). Removes user Y specifically.
Useful but adds complexity.
Distinct from authorization. Authentication: who is this user. Authorization: what can they do.
Wiki manages its own user accounts. Username/password.
For small wikis. Operationally simple; security depends on wiki's auth.
Users authenticate via central identity provider (Google, Microsoft, Okta, GitHub).
For organizations with central identity. Stronger security; user provisioning automated.
Users come from LDAP. Groups come from LDAP.
Common for enterprise wikis. Permissions managed in LDAP, not in the wiki.
Authenticated via SSO; some local accounts for special cases (admins, automation).
Users have only the permissions they need. Not "admin for everyone for convenience."
For sensitive operations, request access; granted temporarily; auto-revokes.
For most wikis, simpler permanent access works. JIT for high-stakes actions.
Groups owned by specific people who decide membership. Avoids "who's in this group" being a free-for-all.
Quarterly: review access. Who has admin? Should they still? Remove inactive users.
Log permission changes. Who granted what to whom.
For regulated environments, required. For others, valuable.
The Wikantik project uses:
policy_grants table, edited under Admin → Security → Policy Grants at /admin/security; see Database-Backed Permissions)groups and group_members tables), edited under Admin → Security → Groups or through /admin/groups[{ALLOW view Admin}]() syntax; list several principals with commas, for example [{ALLOW edit Admin,Editors}]()RestServletBase.checkPagePermission()wikantik.admin.bootstrap) for initial setup or recovery; it applies only to an authenticated session of that login name and lapses after wikantik.admin.bootstrap.maxAgeSeconds (24 hours by default)The model is hybrid: role-based defaults from the policy grants, narrowed by per-page ACLs. A page ACL cannot grant more than the policy allows. When a page carries one, a user needs both the matching role or group grant and an ACL entry that names one of their principals. AllPermission (held through membership of the Admin group) bypasses page ACLs.
Group members, user-type policy grants and user entries in page ACLs all match by login name. A full name or wiki name is editable profile data and never matches. The group editor rejects any member that is not an existing login name with HTTP 400, and a user entry in an ACL matches only an authenticated session whose login is exactly that name. Role and group entries in an ACL are matched by name.
Administrators are the members of the Admin group. A row in the roles table alone is not enough: the account authenticates, but /admin/* answers 403. To give someone one admin area without full rights, add a scoped admin policy grant instead of putting them in the Admin group.
Local accounts live in PostgreSQL and are verified through the JAAS UserDatabaseLoginModule, with bcrypt hashes and a NIST 800-63B-style length and blocklist policy. Single sign-on is optional and additive: OpenID Connect or SAML 2.0 through pac4j, configured with wikantik.sso.*, linking accounts on the immutable sub claim by default (wikantik.sso.identityClaim). SCIM 2.0 at /scim/v2/* lets an identity provider create and deactivate accounts. Wikantik ships no LDAP login module; put an LDAP-capable identity provider in front and use SSO, or supply your own JAAS module through wikantik.loginModule.class.
Programmatic clients use database-backed bearer API keys. A key has a scope rather than page permissions: mcp_read (the read-only /knowledge-mcp endpoint), mcp_admin (the fully privileged /wikantik-admin-mcp endpoint as well), tools (/tools/*) or all. Any logged-in user can mint their own mcp_read or tools key under Preferences → API Keys; mcp_admin and all keys come from an administrator at /admin/apikeys. Key issuance, grant changes and sign-ins are recorded in the hash-chained audit log at /admin/audit. See Connecting Claude Code to the Wikantik MCP Servers for the agent-side setup.
A restricted page never appears in an agent's retrieved context, search
results, or a RAG context bundle for a caller who lacks view permission. View
ACLs are enforced on the read path, not just in the UI: every agent-facing
surface runs its candidate pages through a session view gate
(PageViewGate) before returning them —
/api/*, /wiki/{slug}?format=md|json),/knowledge-mcp retrieval and Knowledge-Graph tools
(retrieve_context, assemble_bundle, search_knowledge, query_nodes, …), and/api/bundle (the RAG context bundle).So restricted content cannot leak into search, retrieval, or a context bundle through the agent interface. (The public RDF/SPARQL surface applies the same guest-view ACL split — only anonymously-viewable pages are materialized.)
On /knowledge-mcp the MCP transport carries no caller identity, so the gate evaluates view ACLs as an anonymous guest: only publicly viewable pages are returned, whichever account owns the key. An agent that must read restricted content has to use the privileged admin endpoint.
Not to be confused with KG Inclusion Policy. View-ACL read-path enforcement is the security boundary and is always on. KG Inclusion Policy is a separate curation control that decides which (already-viewable) pages contribute entities to the Knowledge Graph — it is not access control, and its admin-bypass on KG reads is for curators only and never bypasses a guest's view ACL. KG-including a page does not make a restricted page visible; KG-excluding a page does not hide a viewable page from page search.
Everyone is admin "for convenience." Compromised account = compromised wiki.
Per-page ACLs accumulate; no one knows who has access to what.
For wikis with thousands of pages, sprawl becomes unmanageable. Use group-based access where possible.
Permissions changed frequently for ad-hoc needs. Hard to audit.
Standardize: groups for common needs; ACLs for exceptions.
Permission changes happen; no record. Can't investigate after the fact.
Users left the company; still have access.
Auto-revoke on user deactivation; periodic review.
For public wikis; the right answer. For internal wikis with sensitive content; the wrong answer. Verify what's intended.
For new internal wikis:
For public wikis: anonymous read; authenticated edit; admin role for trusted users.
Depends on culture. Wikipedia: yes, anyone edits. Internal corporate: usually no.
For public wikis: yes (the point). For internal: rarely.
Per page: who edited what. Most wikis show this; some hide for privacy reasons.
Often a separate, more restricted permission. Deletion is rarely needed; risky.
Cluster Hub: Wikantik Platform Development Hub: Architecture, MCP Protocols, and Agent Briefings (wikantik-development)