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