Skip to Content
Version 3.1 by Agnease on 2026/06/02 11:07
Hide last authors
Agnease 3.1 1 {{velocity}}
2 #set ($discard = $xwiki.ssx.use('PublicWebSite.WebHome'))
3 {{html clean="false"}}
4
5 <section class="resource-header" aria-labelledby="hero-title">
6 <div class="container">
7 <div class="text-center">
8 <div class="hero-kicker">
9 <i class="fa fa-lock" aria-hidden="true"></i>
10 XWiki access rights guidance
11 </div>
12 </div>
13
14 <h1 id="hero-title">Why XWiki access rights need a clear governance model</h1>
15
16 <p class="resource-summary">
17 XWiki permissions are powerful and flexible, but they can become difficult to manage when groups,
18 inherited rights and page-level exceptions grow without a clear access model.
19 </p>
20 </div>
21 </section>
22
23 <section class="resource-page">
24 <div class="container">
25 <div class="resource-layout">
26
27 <aside class="resource-sidebar" aria-label="Page summary">
28 <h4>In this guide</h4>
29 <ul>
30 <li><a href="#why-it-matters">Why it matters</a></li>
31 <li><a href="#where-problems-appear">Where problems appear</a></li>
32 <li><a href="#governance-model">Governance model</a></li>
33 <li><a href="#rights-checklist">Checklist</a></li>
34 <li><a href="#when-to-review">When to review</a></li>
35 <li><a href="#access-rights-faq">FAQ</a></li>
36 </ul>
37 </aside>
38
39 <article class="resource-content">
40
41 <p>
42 Many XWiki access-rights problems do not appear because the platform lacks flexibility. They appear because
43 permissions were added over time without a clear model. A team needs access, a page is restricted, a group is
44 created, an exception is added, and after a few years nobody is completely sure who can access what.
45 </p>
46
47 <p>
48 This is especially important when XWiki is used as an intranet, documentation platform, knowledge base,
49 project workspace or controlled document system. The wiki may contain internal procedures, customer data,
50 technical documentation, HR content, compliance records or business-critical workflows.
51 </p>
52
53 <div class="resource-note">
54 <p>
55 <strong>In practice:</strong> XWiki access rights should be managed through groups, clear ownership,
56 documented restricted areas, controlled exceptions and periodic reviews. The goal is to make permissions
57 understandable, not only technically correct.
58 </p>
59 </div>
60
61 <p>
62 An XWiki access-rights governance model defines how users, groups, wiki-level rights, page-level rights,
63 inherited permissions and sensitive privileges are managed over time. It helps administrators avoid accidental
64 exposure, unnecessary restrictions and permission rules that become impossible to explain later.
65 </p>
66
67 <div class="resource-note">
68 <p>
69 <strong>The main point:</strong> XWiki permissions should not only answer “can this user access this page?”
70 They should also answer “why does this user have access, who approved it and how will we review it later?”
71 </p>
72 </div>
73
74 <h2 id="why-it-matters">Why XWiki access rights governance matters</h2>
75
76 <p>
77 XWiki allows rights to be configured at different levels, including globally and on specific pages or page
78 hierarchies. This flexibility is useful because different areas of the wiki may need different access models:
79 public internal knowledge, team spaces, restricted projects, administrative areas or confidential documents.
80 </p>
81
82 <p>
83 But flexibility also creates responsibility. If every restriction is handled as a one-off exception, the
84 permission model becomes harder to maintain. Administrators may hesitate to change anything because they do not
85 know what depends on the current configuration.
86 </p>
87
88 <p>
89 A clear governance model makes access control easier to audit, easier to explain and safer to evolve. It also
90 reduces the risk of giving too much access to the wrong users or blocking people who need access to do their
91 work.
92 </p>
93
94 <h2 id="where-problems-appear">Where XWiki permission problems usually appear</h2>
95
96 <h3>1. Rights assigned to individual users</h3>
97 <p>
98 Assigning rights directly to users may look convenient for small changes, but it becomes difficult to maintain
99 when people change roles, leave the organization or move between teams. Groups should usually be the foundation
100 of the access model.
101 </p>
102
103 <h3>2. Too many page-level exceptions</h3>
104 <p>
105 Page-level rights are useful, especially for restricted areas or sensitive content. The problem appears when
106 exceptions are added repeatedly without documentation. Over time, the effective access model may no longer be
107 obvious from the wiki structure.
108 </p>
109
110 <h3>3. Unclear inherited permissions</h3>
111 <p>
112 Inherited rights can make administration efficient, but they can also surprise administrators when a parent
113 page or higher-level configuration affects a large set of child pages. Restricted spaces and sensitive page
114 trees should be reviewed with inheritance in mind.
115 </p>
116
117 <h3>4. Old groups and inactive users</h3>
118 <p>
119 Many permission issues come from groups that were created for old projects, former teams or temporary access.
120 If these groups remain active, they may continue to grant access long after the original need disappeared.
121 </p>
122
123 <h3>5. Powerful rights granted too broadly</h3>
124 <p>
125 Administration, script and programming rights need special attention. These rights can affect more than normal
126 content editing and should be limited to trusted users who understand the technical and security impact.
127 </p>
128
129 <p>
130 For a broader view of platform-level risks, see
131 <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>.
132 </p>
133
134 <div class="resource-inline-cta">
135 <p>
136 <strong>Not sure whether your XWiki permissions are still clear?</strong>
137 An access-rights review can help identify old groups, broad permissions, confusing exceptions and sensitive
138 areas that need a cleaner governance model.
139 </p>
140 <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request an access review</a>
141 </div>
142
143 <h2 id="governance-model">A safer model for XWiki access rights</h2>
144
145 <h3>1. Define access areas before configuring rights</h3>
146 <p>
147 Start by identifying the main categories of content: open internal knowledge, team workspaces, restricted
148 projects, confidential areas and administrative pages. This makes the rights model easier to explain before
149 individual permissions are configured.
150 </p>
151
152 <h3>2. Use groups as the main access-control layer</h3>
153 <p>
154 Groups make permission management more stable. Instead of granting rights to individual users, create groups
155 that represent roles or access needs, such as editors, reviewers, project members, administrators or external
156 collaborators.
157 </p>
158
159 <h3>3. Keep page-level exceptions intentional</h3>
160 <p>
161 Exceptions should be used when they solve a clear access problem, not as the default way to manage the wiki.
162 When a page or page hierarchy needs special rights, document why the restriction exists and who owns it.
163 </p>
164
165 <h3>4. Treat sensitive rights separately</h3>
166 <p>
167 Administration, script and programming rights should not be managed like normal edit rights. They should be
168 reviewed separately, limited to trusted users and documented as part of the technical administration model.
169 </p>
170
171 <h3>5. Review permissions as the organization changes</h3>
172 <p>
173 Access rights should not be configured once and forgotten. Teams change, projects end, users leave, new
174 authentication systems are introduced and the wiki grows. A regular review helps keep permissions aligned with
175 the real organization.
176 </p>
177
178 <h2 id="rights-checklist">XWiki access-rights governance checklist</h2>
179
180 <p>
181 A practical XWiki access-rights review should check both the permission configuration and the way permissions
182 are managed over time. The following checklist can be used as a starting point.
183 </p>
184
185 <ul class="resource-checklist">
186 <li>Identify public, internal, restricted and administrative areas of the wiki.</li>
187 <li>Review who has wiki administration rights.</li>
188 <li>Review script and programming rights separately from normal edit rights.</li>
189 <li>Check whether rights are assigned through groups rather than individual users.</li>
190 <li>Review inherited permissions and page-level exceptions.</li>
191 <li>Check old groups, inactive users and temporary access that may still be active.</li>
192 <li>Verify that sensitive spaces and page trees have clear owners.</li>
193 <li>Document why restricted areas exist and who should approve access changes.</li>
194 <li>Review authentication and group synchronization if LDAP, SSO, OIDC or SAML is used.</li>
195 <li>Schedule periodic access-rights reviews instead of waiting for a problem.</li>
196 </ul>
197
198 <h2 id="when-to-review">When should XWiki access rights be reviewed?</h2>
199
200 <p>
201 Access rights should be reviewed before a major upgrade, after an authentication change, after a migration,
202 when external users are added, when a wiki becomes business-critical or when administration responsibility
203 moves to a new team.
204 </p>
205
206 <p>
207 A review is also useful after years of organic growth. Even when permissions were correct at the time they
208 were added, they may no longer reflect the current structure of the organization.
209 </p>
210
211 <p>
212 The best result is not only a safer wiki. It is a wiki where administrators can clearly explain how access is
213 granted, which groups matter, where exceptions exist and what should be reviewed in the future.
214 </p>
215
216 <h2 id="access-rights-faq">XWiki access rights FAQ</h2>
217
218 <details class="resource-faq-item" open>
219 <summary>Should XWiki rights be assigned to users or groups?</summary>
220 <p>
221 In most cases, rights should be assigned to groups. Groups are easier to maintain when users change roles,
222 join teams or leave the organization. Direct user rights should be limited and reviewed carefully.
223 </p>
224 </details>
225
226 <details class="resource-faq-item">
227 <summary>Are page-level permissions bad in XWiki?</summary>
228 <p>
229 No. Page-level permissions are useful for restricted areas and sensitive content. The risk appears when too
230 many exceptions are added without documentation, making the effective access model difficult to understand.
231 </p>
232 </details>
233
234 <details class="resource-faq-item">
235 <summary>Why should admin, script and programming rights be reviewed separately?</summary>
236 <p>
237 These rights can have a broader technical and security impact than normal view or edit permissions. They
238 should be granted only to trusted users who understand the implications and should be reviewed regularly.
239 </p>
240 </details>
241
242 <details class="resource-faq-item">
243 <summary>Does SSO automatically solve XWiki access control?</summary>
244 <p>
245 No. SSO helps authenticate users, but authorization still depends on XWiki groups, rights, inherited
246 permissions and page-level exceptions. Authentication and access control should be reviewed together.
247 </p>
248 </details>
249
250 <details class="resource-faq-item">
251 <summary>How often should XWiki permissions be reviewed?</summary>
252 <p>
253 The review frequency depends on the organization, but access rights should be reviewed regularly and after
254 important changes such as team reorganizations, authentication updates, migrations, external user onboarding
255 or major changes to the wiki structure.
256 </p>
257 </details>
258
259 <div class="resource-note">
260 <p>
261 Related resources:
262 <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>,
263 <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>
264 and
265 <a href="$xwiki.getURL('resources.xwiki-custom-development')">how to keep XWiki custom development maintainable across upgrades</a>.
266 </p>
267 </div>
268
269 <div class="resource-cta">
270 <h3>Need help reviewing XWiki access rights?</h3>
271 <p>
272 If your XWiki instance has grown over time, includes restricted areas, uses many groups or depends on
273 authentication integrations, an access-rights review can help clarify who can access what and where the
274 permission model should be simplified.
275 </p>
276 <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request an access-rights review</a>
277 </div>
278
279 </article>
280 </div>
281 </div>
282 </section>
283
284 <script type="application/ld+json">
285 {
286 "@context": "https://schema.org",
287 "@type": "FAQPage",
288 "mainEntity": [
289 {
290 "@type": "Question",
291 "name": "Should XWiki rights be assigned to users or groups?",
292 "acceptedAnswer": {
293 "@type": "Answer",
294 "text": "In most cases, XWiki rights should be assigned to groups. Groups are easier to maintain when users change roles, join teams or leave the organization. Direct user rights should be limited and reviewed carefully."
295 }
296 },
297 {
298 "@type": "Question",
299 "name": "Are page-level permissions bad in XWiki?",
300 "acceptedAnswer": {
301 "@type": "Answer",
302 "text": "No. Page-level permissions are useful for restricted areas and sensitive content. The risk appears when too many exceptions are added without documentation, making the effective access model difficult to understand."
303 }
304 },
305 {
306 "@type": "Question",
307 "name": "Why should admin, script and programming rights be reviewed separately?",
308 "acceptedAnswer": {
309 "@type": "Answer",
310 "text": "Admin, script and programming rights can have a broader technical and security impact than normal view or edit permissions. They should be granted only to trusted users who understand the implications and should be reviewed regularly."
311 }
312 },
313 {
314 "@type": "Question",
315 "name": "Does SSO automatically solve XWiki access control?",
316 "acceptedAnswer": {
317 "@type": "Answer",
318 "text": "No. SSO helps authenticate users, but authorization still depends on XWiki groups, rights, inherited permissions and page-level exceptions. Authentication and access control should be reviewed together."
319 }
320 },
321 {
322 "@type": "Question",
323 "name": "How often should XWiki permissions be reviewed?",
324 "acceptedAnswer": {
325 "@type": "Answer",
326 "text": "The review frequency depends on the organization, but access rights should be reviewed regularly and after important changes such as team reorganizations, authentication updates, migrations, external user onboarding or major changes to the wiki structure."
327 }
328 }
329 ]
330 }
331 </script>
332
333 {{/html}}
334 {{/velocity}}