Skip to Content
Version 2.4 by Agnease on 2026/06/08 18:05
Show last authors
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-search" aria-hidden="true"></i>
10 XWiki access-rights review
11 </div>
12 </div>
13
14 <h1 id="hero-title">How to start an XWiki access-rights review</h1>
15
16 <p class="resource-summary">
17 A practical first step for identifying local rights, old groups, sensitive permissions and unclear access exceptions
18 before they become a security or maintenance problem.
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-review">Why review access rights</a></li>
31 <li><a href="#access-model">Start with the model</a></li>
32 <li><a href="#review-groups">Review groups</a></li>
33 <li><a href="#find-local-rights">Find local rights</a></li>
34 <li><a href="#sensitive-rights">Sensitive rights</a></li>
35 <li><a href="#document-findings">Document findings</a></li>
36 <li><a href="#review-checklist">Checklist</a></li>
37 <li><a href="#access-review-faq">FAQ</a></li>
38 </ul>
39 </aside>
40
41 <article class="resource-content">
42
43 <p>
44 Many XWiki permission issues are not visible from the homepage. Users can log in, pages can be edited,
45 search can work correctly, and the wiki may still contain access rules that nobody fully understands anymore.
46 </p>
47
48 <p>
49 This usually happens slowly. A team needs access, a page is restricted, a group is created, an exception is
50 added, an external user is invited, and after a few years the access model becomes difficult to explain.
51 </p>
52
53 <div class="resource-note">
54 <p>
55 <strong>In practice:</strong> an XWiki access-rights review should start by understanding the intended
56 access model, then checking groups, local page rights, inherited permissions, powerful rights, inactive users
57 and undocumented exceptions.
58 </p>
59 </div>
60
61 <p>
62 An XWiki access-rights review is a structured check of how users and groups receive permissions across the wiki.
63 It helps administrators understand who can access what, why access was granted, which permissions are inherited,
64 and where local exceptions may create risk or confusion.
65 </p>
66
67 <div class="resource-note">
68 <p>
69 <strong>The main point:</strong> the goal is not only to find permission problems. The goal is to make the
70 access model easier to explain, maintain and review over time.
71 </p>
72 </div>
73
74 <h2 id="why-review">Why an access-rights review matters</h2>
75
76 <p>
77 XWiki is often used for internal knowledge, project documentation, procedures, HR content, customer information,
78 technical documentation, controlled documents or business-critical workflows. When the content becomes important,
79 the access model becomes important too.
80 </p>
81
82 <p>
83 A permission setup can be technically valid and still be difficult to govern. For example, rights may be assigned
84 to individual users instead of groups, old project groups may still have access, or page-level exceptions may
85 override the expected inherited model.
86 </p>
87
88 <p>
89 For a broader view of security-related checks, see
90 <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>.
91 </p>
92
93 <h2 id="access-model">1. Start with the access model, not with the UI</h2>
94
95 <p>
96 Before changing permissions, clarify what the wiki should look like from an access perspective. Otherwise,
97 the review becomes a list of isolated technical checks without a clear target.
98 </p>
99
100 <p>
101 A simple model is often enough. Separate the wiki into clear areas such as open internal knowledge,
102 team spaces, restricted projects, confidential documents, technical administration pages and external
103 collaboration areas.
104 </p>
105
106 <table class="table table-bordered table-striped">
107 <thead>
108 <tr>
109 <th>Area type</th>
110 <th>Typical access</th>
111 <th>Review question</th>
112 </tr>
113 </thead>
114 <tbody>
115 <tr>
116 <td>Open internal knowledge</td>
117 <td>Most authenticated users can view, selected users can edit</td>
118 <td>Is this content really safe for broad internal access?</td>
119 </tr>
120 <tr>
121 <td>Team or project spaces</td>
122 <td>Team members can edit, others may only view</td>
123 <td>Are the groups still aligned with the current team?</td>
124 </tr>
125 <tr>
126 <td>Restricted projects</td>
127 <td>Only selected groups can view or edit</td>
128 <td>Is access granted through groups or individual users?</td>
129 </tr>
130 <tr>
131 <td>Confidential documents</td>
132 <td>Small controlled group</td>
133 <td>Who owns the restriction and when was it last reviewed?</td>
134 </tr>
135 <tr>
136 <td>Technical administration pages</td>
137 <td>Trusted administrators only</td>
138 <td>Are admin, script and programming rights limited?</td>
139 </tr>
140 </tbody>
141 </table>
142
143 <h2 id="review-groups">2. Review groups before reviewing pages</h2>
144
145 <p>
146 In most XWiki instances, groups should be the foundation of the permission model. Rights assigned directly to
147 individual users are harder to maintain because people change roles, leave the organization or move between teams.
148 </p>
149
150 <p>
151 Start by reviewing which groups exist, what they are used for and whether their members still match the intended
152 access model.
153 </p>
154
155 <table class="table table-bordered table-striped">
156 <thead>
157 <tr>
158 <th>Group review item</th>
159 <th>What to check</th>
160 <th>Possible action</th>
161 </tr>
162 </thead>
163 <tbody>
164 <tr>
165 <td>Old project groups</td>
166 <td>Groups created for projects that ended</td>
167 <td>Remove access, archive the group or document why it remains active</td>
168 </tr>
169 <tr>
170 <td>Inactive users</td>
171 <td>Users who no longer need access</td>
172 <td>Remove from groups or deactivate accounts according to policy</td>
173 </tr>
174 <tr>
175 <td>Unclear group names</td>
176 <td>Groups whose purpose is not obvious</td>
177 <td>Rename, document or consolidate</td>
178 </tr>
179 <tr>
180 <td>Overloaded groups</td>
181 <td>Groups used for too many unrelated areas</td>
182 <td>Split into clearer role-based or area-based groups</td>
183 </tr>
184 <tr>
185 <td>Admin groups</td>
186 <td>Groups with powerful rights</td>
187 <td>Review membership separately and keep it limited</td>
188 </tr>
189 </tbody>
190 </table>
191
192 <h2 id="find-local-rights">3. Identify pages with local access rights</h2>
193
194 <p>
195 Local page-level rights are often where surprises appear. They are useful when a page or page hierarchy needs
196 special access rules, but they can become difficult to manage when they are added repeatedly without documentation.
197 </p>
198
199 <p>
200 The following Velocity snippet can help you start the review by listing pages that contain local
201 <code>XWiki.XWikiRights</code> objects. It is not a complete audit, but it gives you a practical first list of
202 places where local rights may exist.
203 </p>
204 {{/html}}
205 {{code language="velocity"}}
206 #set ($query = "select distinct doc.fullName from XWikiDocument doc, BaseObject obj where obj.name = doc.fullName and obj.className = 'XWiki.XWikiRights' order by doc.fullName asc")
207 #set ($pages = $services.query.xwql($query).execute())
208
209 #if ($pages.isEmpty())
210 No pages with local XWiki rights were found.
211 #else
212 |= Page |= Local rights found
213 #foreach ($page in $pages)
214 | [[$page]] | yes
215 #end
216 #end
217 {{/code}}
218
219 {{html clean="false"}}
220 <p>
221 Use the result as a starting point. Each page should be reviewed in context: why local rights were added, which
222 users or groups are affected, whether rights apply only to that page or to a hierarchy, and whether the exception
223 is still needed.
224 </p>
225
226 <div class="resource-note">
227 <p>
228 <strong>Important:</strong> a list of pages with local rights does not tell the full story. You still need to
229 interpret inherited permissions, groups, explicit allow or deny rules, wiki-level rights and sensitive rights
230 such as admin, script or programming.
231 </p>
232 </div>
233
234 <div class="resource-inline-cta">
235 <p>
236 <strong>Not sure where local rights are hidden?</strong>
237 A focused access-rights review can help identify local exceptions, inherited permissions, old groups and
238 sensitive rights that should be cleaned up or documented.
239 </p>
240 <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request an access review</a>
241 </div>
242
243 <h2 id="sensitive-rights">4. Pay special attention to sensitive rights</h2>
244
245 <p>
246 Not all rights have the same impact. View, comment and edit rights affect content collaboration. Administration,
247 script and programming rights can have a broader technical and security impact and should be reviewed separately.
248 </p>
249
250 <p>
251 A user with powerful rights may be able to change configuration, execute advanced scripts, affect other users or
252 influence how content is rendered. These rights should be granted intentionally, limited to trusted users and
253 documented as part of the administration model.
254 </p>
255
256 <table class="table table-bordered table-striped">
257 <thead>
258 <tr>
259 <th>Right type</th>
260 <th>Why it matters</th>
261 <th>Review approach</th>
262 </tr>
263 </thead>
264 <tbody>
265 <tr>
266 <td>Admin</td>
267 <td>Can control important wiki configuration and rights</td>
268 <td>Keep limited and review membership regularly</td>
269 </tr>
270 <tr>
271 <td>Script</td>
272 <td>Can allow advanced scripting behavior depending on context</td>
273 <td>Grant only to users who understand the technical impact</td>
274 </tr>
275 <tr>
276 <td>Programming</td>
277 <td>Can be highly sensitive and should be reserved for trusted technical administrators</td>
278 <td>Review separately from normal editing permissions</td>
279 </tr>
280 <tr>
281 <td>Edit</td>
282 <td>Allows content changes and may affect business processes</td>
283 <td>Assign through groups and validate restricted areas</td>
284 </tr>
285 <tr>
286 <td>View</td>
287 <td>Controls access to content and confidential information</td>
288 <td>Review public, internal and restricted areas carefully</td>
289 </tr>
290 </tbody>
291 </table>
292
293 <h2 id="document-findings">5. Document the findings</h2>
294
295 <p>
296 An access-rights review should not end with a few manual changes. The result should be documented so that the
297 next administrator understands what was found, what was changed and what still needs attention.
298 </p>
299
300 <p>
301 A simple review register can be enough. The goal is to record the affected area, the current access model, the
302 risk, the owner and the recommended action.
303 </p>
304
305 <table class="table table-bordered table-striped">
306 <thead>
307 <tr>
308 <th>Area or page</th>
309 <th>Current access</th>
310 <th>Risk or concern</th>
311 <th>Recommended action</th>
312 <th>Owner</th>
313 <th>Review date</th>
314 </tr>
315 </thead>
316 <tbody>
317 <tr>
318 <td>Example.ProjectSpace</td>
319 <td>Old project group can still view</td>
320 <td>Project ended, access may no longer be needed</td>
321 <td>Confirm owner and remove group if obsolete</td>
322 <td>Project owner</td>
323 <td>YYYY-MM-DD</td>
324 </tr>
325 <tr>
326 <td>Example.ConfidentialDocs</td>
327 <td>Individual users have direct rights</td>
328 <td>Difficult to maintain when roles change</td>
329 <td>Move access to a dedicated group</td>
330 <td>Content owner</td>
331 <td>YYYY-MM-DD</td>
332 </tr>
333 </tbody>
334 </table>
335
336 <h2 id="review-checklist">XWiki access-rights review checklist</h2>
337
338 <p>
339 A practical review should combine technical checks with governance questions. The following checklist can be
340 used as a starting point before changing permissions in production.
341 </p>
342
343 <ul class="resource-checklist">
344 <li>Identify public, internal, restricted and administrative areas.</li>
345 <li>List active groups and clarify what each group is used for.</li>
346 <li>Review old groups, inactive users and temporary access.</li>
347 <li>Identify pages with local XWiki rights objects.</li>
348 <li>Review page-level exceptions and inherited permissions.</li>
349 <li>Check whether rights are assigned to groups rather than individual users.</li>
350 <li>Review admin, script and programming rights separately.</li>
351 <li>Check authentication and group synchronization if LDAP, SSO, OIDC or SAML is used.</li>
352 <li>Document findings, owners, risks and recommended actions.</li>
353 <li>Schedule a periodic access-rights review.</li>
354 </ul>
355
356 <h2 id="access-review-faq">XWiki access-rights review FAQ</h2>
357
358 <details class="resource-faq-item" open>
359 <summary>Is listing pages with local rights enough for an access audit?</summary>
360 <p>
361 No. It is only a starting point. A complete review should also consider inherited permissions, group
362 membership, wiki-level rights, explicit allow or deny rules, sensitive rights and the business reason behind
363 each restricted area.
364 </p>
365 </details>
366
367 <details class="resource-faq-item">
368 <summary>Should XWiki rights be assigned directly to users?</summary>
369 <p>
370 In most cases, rights should be assigned through groups. Direct user rights can be useful in rare situations,
371 but they are harder to maintain and should be reviewed carefully.
372 </p>
373 </details>
374
375 <details class="resource-faq-item">
376 <summary>What is the most common access-rights problem in XWiki?</summary>
377 <p>
378 A common issue is the accumulation of undocumented exceptions: old groups, page-level rights, inherited
379 permissions and direct user rights that were correct at the time but are no longer clearly understood.
380 </p>
381 </details>
382
383 <details class="resource-faq-item">
384 <summary>Should access rights be reviewed before an XWiki upgrade?</summary>
385 <p>
386 Yes. Upgrades are a good moment to review permissions, especially for business-critical instances. The review
387 can reveal old groups, sensitive rights, custom scripts and restricted areas that should be validated during
388 the upgrade process.
389 </p>
390 </details>
391
392 <details class="resource-faq-item">
393 <summary>Does SSO replace an access-rights review?</summary>
394 <p>
395 No. SSO helps authenticate users, but XWiki authorization still depends on groups, rights, inheritance and
396 page-level exceptions. Authentication and access control should be reviewed together.
397 </p>
398 </details>
399
400 <div class="resource-note">
401 <p>
402 Related resources:
403 <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>,
404 <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>
405 and
406 <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>.
407 </p>
408 </div>
409
410 <div class="resource-cta">
411 <h3>Need help reviewing XWiki access rights?</h3>
412 <p>
413 If your XWiki instance has grown over time, uses many groups, contains restricted areas or depends on LDAP,
414 SSO, OIDC or SAML, an access-rights review can help identify unclear permissions and define a safer model.
415 </p>
416 <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request an access-rights review</a>
417 </div>
418
419 </article>
420 </div>
421 </div>
422 </section>
423
424 <script type="application/ld+json">
425 {
426 "@context": "https://schema.org",
427 "@type": "FAQPage",
428 "mainEntity": [
429 {
430 "@type": "Question",
431 "name": "Is listing pages with local rights enough for an access audit?",
432 "acceptedAnswer": {
433 "@type": "Answer",
434 "text": "No. It is only a starting point. A complete review should also consider inherited permissions, group membership, wiki-level rights, explicit allow or deny rules, sensitive rights and the business reason behind each restricted area."
435 }
436 },
437 {
438 "@type": "Question",
439 "name": "Should XWiki rights be assigned directly to users?",
440 "acceptedAnswer": {
441 "@type": "Answer",
442 "text": "In most cases, rights should be assigned through groups. Direct user rights can be useful in rare situations, but they are harder to maintain and should be reviewed carefully."
443 }
444 },
445 {
446 "@type": "Question",
447 "name": "What is the most common access-rights problem in XWiki?",
448 "acceptedAnswer": {
449 "@type": "Answer",
450 "text": "A common issue is the accumulation of undocumented exceptions: old groups, page-level rights, inherited permissions and direct user rights that were correct at the time but are no longer clearly understood."
451 }
452 },
453 {
454 "@type": "Question",
455 "name": "Should access rights be reviewed before an XWiki upgrade?",
456 "acceptedAnswer": {
457 "@type": "Answer",
458 "text": "Yes. Upgrades are a good moment to review permissions, especially for business-critical instances. The review can reveal old groups, sensitive rights, custom scripts and restricted areas that should be validated during the upgrade process."
459 }
460 },
461 {
462 "@type": "Question",
463 "name": "Does SSO replace an access-rights review?",
464 "acceptedAnswer": {
465 "@type": "Answer",
466 "text": "No. SSO helps authenticate users, but XWiki authorization still depends on groups, rights, inheritance and page-level exceptions. Authentication and access control should be reviewed together."
467 }
468 }
469 ]
470 }
471 </script>
472
473 {{/html}}
474 {{/velocity}}