Changes for page How to start an XWiki access-rights review

Last modified by Agnease on 2026/06/08 18:37

Manage
- Copy
Actions
- Export
- Print Preview
Viewers
- Source
- Siblings
- Content
- Comments
- Attachments
- History
- Information
- Likes

From 2.9 to 2.10

From version 2.10

edited by Agnease
on 2026/06/08 18:12

Change comment: There is no comment for this version

To version 2.12

edited by Agnease
on 2026/06/08 18:37

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -11,10 +11,10 @@
          </div>
        </div>
--      <h1 id="hero-title">How to start an XWiki access-rights review</h1>
++      <h1 id="hero-title">A first-pass XWiki access-rights audit before changing permissions</h1>
        <p class="resource-summary">
--        A practical first step for identifying local rights, old groups, sensitive permissions and unclear access exceptions
++        A practical way to identify local rights, old groups, sensitive permissions and unclear access exceptions
          before they become a security or maintenance problem.
        </p>
      </div>
@@ -27,12 +27,14 @@
          <aside class="resource-sidebar" aria-label="Page summary">
            <h4>In this guide</h4>
            <ul>
--            <li><a href="#why-review">Why review access rights</a></li>
--            <li><a href="#access-model">Start with the model</a></li>
--            <li><a href="#review-groups">Review groups</a></li>
--            <li><a href="#find-local-rights">Find local rights</a></li>
--            <li><a href="#sensitive-rights">Sensitive rights</a></li>
--            <li><a href="#document-findings">Document findings</a></li>
++            <li><a href="#starting-point">Where to start</a></li>
++            <li><a href="#first-pass-audit">First-pass audit</a></li>
++            <li><a href="#access-model">Access areas</a></li>
++            <li><a href="#review-groups">Groups and users</a></li>
++            <li><a href="#find-local-rights">Local rights snippet</a></li>
++            <li><a href="#interpret-results">How to interpret results</a></li>
++            <li><a href="#common-findings">Common findings</a></li>
++            <li><a href="#document-findings">Review register</a></li>
              <li><a href="#review-checklist">Checklist</a></li>
              <li><a href="#access-review-faq">FAQ</a></li>
            </ul>
@@ -41,6 +41,11 @@
          <article class="resource-content">
            <p>
++            When I review an existing XWiki instance, I do not start by changing permissions. I first try to understand
++            where access rules have accumulated over time.
++          </p>
++
++          <p>
              Many XWiki permission issues are not visible from the homepage. Users can log in, pages can be edited,
              search can work correctly, and the wiki may still contain access rules that nobody fully understands anymore.
            </p>
@@ -52,53 +52,63 @@
            <div class="resource-note">
              <p>
--              <strong>In practice:</strong> an XWiki access-rights review should start by understanding the intended
--              access model, then checking groups, local page rights, inherited permissions, powerful rights, inactive users
--              and undocumented exceptions.
++              <strong>In practice:</strong> the first review should not try to rebuild the whole permission model.
++              It should identify risky areas, unclear exceptions, old groups and sensitive rights that need a closer look.
              </p>
            </div>
++          <h2 id="starting-point">Where to start in a real XWiki instance</h2>
++
            <p>
--            An XWiki access-rights review is a structured check of how users and groups receive permissions across the wiki.
--            It helps administrators understand who can access what, why access was granted, which permissions are inherited,
--            and where local exceptions may create risk or confusion.
++            The first signs of a messy access model are usually simple: many groups with unclear names, rights assigned
++            directly to users, restricted pages without an owner, old project spaces and powerful rights granted to people
++            who no longer administer the platform.
            </p>
++          <p>
++            At this stage, the goal is not to decide whether every permission is correct. The goal is to build a map:
++            which areas are sensitive, where local rights exist, which groups matter, and which findings should be reviewed
++            before the next upgrade, migration or authentication change.
++          </p>
++
            <div class="resource-note">
              <p>
--              <strong>The main point:</strong> the goal is not only to find permission problems. The goal is to make the
--              access model easier to explain, maintain and review over time.
++              <strong>The main point:</strong> a useful access-rights review should answer more than “can this user access
++              this page?” It should also answer “why do they have access, which group grants it, who owns the area and when
++              should this be reviewed again?”
              </p>
            </div>
--          <h2 id="why-review">Why an access-rights review matters</h2>
--
            <p>
--            XWiki is often used for internal knowledge, project documentation, procedures, HR content, customer information,
--            technical documentation, controlled documents or business-critical workflows. When the content becomes important,
--            the access model becomes important too.
++            For a broader view of security-related checks, see
++            <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>.
            </p>
--          <p>
--            A permission setup can be technically valid and still be difficult to govern. For example, rights may be assigned
--            to individual users instead of groups, old project groups may still have access, or page-level exceptions may
--            override the expected inherited model.
--          </p>
++          <h2 id="first-pass-audit">A practical first-pass audit</h2>
            <p>
--            For a broader view of security-related checks, see
--            <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>.
++            A first-pass audit should be safe and observational. Before changing anything in production, collect enough
++            information to understand the current model and the areas that need attention.
            </p>
--          <h2 id="access-model">1. Start with the access model, not with the UI</h2>
++          <ul class="resource-checklist">
++            <li>Do not change permissions before understanding why they exist.</li>
++            <li>Identify the main areas of the wiki: open, internal, restricted, confidential and administrative.</li>
++            <li>List the groups that seem to control access to these areas.</li>
++            <li>Look for direct user rights and local page-level exceptions.</li>
++            <li>Review admin, script and programming rights separately from normal edit rights.</li>
++            <li>Document what is unclear instead of guessing.</li>
++          </ul>
++          <h2 id="access-model">1. Start with access areas, not individual pages</h2>
++
            <p>
--            Before changing permissions, clarify what the wiki should look like from an access perspective. Otherwise,
--            the review becomes a list of isolated technical checks without a clear target.
++            Before reviewing individual permissions, clarify what the wiki should look like from an access perspective.
++            Otherwise, the review becomes a list of isolated technical checks without a clear target.
            </p>
            <p>
--            A simple model is often enough. Separate the wiki into clear areas such as open internal knowledge,
++            A simple access map is often enough. Separate the wiki into clear areas such as open internal knowledge,
              team spaces, restricted projects, confidential documents, technical administration pages and external
              collaboration areas.
            </p>
@@ -108,7 +108,7 @@
                <tr>
                  <th>Area type</th>
                  <th>Typical access</th>
--                <th>Review question</th>
++                <th>First review question</th>
                </tr>
              </thead>
              <tbody>
@@ -149,42 +149,43 @@
            <p>
              Start by reviewing which groups exist, what they are used for and whether their members still match the intended
--            access model.
++            access model. Group names often tell part of the story: old project names, temporary access groups and unclear
++            role names are good signals that the access model needs cleanup.
            </p>
            <table class="table table-bordered table-striped">
              <thead>
                <tr>
--                <th>Group review item</th>
--                <th>What to check</th>
--                <th>Possible action</th>
++                <th>Group signal</th>
++                <th>What it may indicate</th>
++                <th>First action</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td>Old project groups</td>
--                <td>Groups created for projects that ended</td>
--                <td>Remove access, archive the group or document why it remains active</td>
++                <td>A project ended but access may still be active</td>
++                <td>Confirm whether the group is still needed</td>
                </tr>
                <tr>
                  <td>Inactive users</td>
--                <td>Users who no longer need access</td>
--                <td>Remove from groups or deactivate accounts according to policy</td>
++                <td>Former employees or old accounts may still have access</td>
++                <td>Remove from groups or deactivate according to policy</td>
                </tr>
                <tr>
                  <td>Unclear group names</td>
--                <td>Groups whose purpose is not obvious</td>
--                <td>Rename, document or consolidate</td>
++                <td>Nobody can easily explain what the group controls</td>
++                <td>Document, rename or consolidate</td>
                </tr>
                <tr>
                  <td>Overloaded groups</td>
--                <td>Groups used for too many unrelated areas</td>
++                <td>One group controls too many unrelated areas</td>
                  <td>Split into clearer role-based or area-based groups</td>
                </tr>
                <tr>
                  <td>Admin groups</td>
--                <td>Groups with powerful rights</td>
--                <td>Review membership separately and keep it limited</td>
++                <td>Powerful rights may be granted too broadly</td>
++                <td>Review membership separately</td>
                </tr>
              </tbody>
            </table>
@@ -198,13 +198,13 @@
            <p>
              The following Velocity snippet can help you start the review by listing pages that contain local
--            <code>XWiki.XWikiRights</code> objects. It is not a complete audit, but it gives you a practical first list of
--            places where local rights may exist.
++            <code>XWiki.XWikiRights</code> objects. It is not a complete audit. It gives you a practical first list of
++            pages where local rights may exist.
            </p>
  {{/html}}
  {{/velocity}}
--{{code}}
++{{code language="velocity"}}
  #set ($query = "from doc.object(XWiki.XWikiRights) rights order by doc.fullName asc")
  #set ($pages = $services.query.xwql($query).execute())
@@ -211,9 +211,9 @@
  #if ($pages.isEmpty())
    No pages with local XWiki rights were found.
  #else
--  |= Page |= Local rights found
++  |= Page |= Review note
    #foreach ($page in $pages)
--    | [[$page]] | yes
++    | [[$page]] | Local rights configured
    #end
  #end
  {{/code}}
@@ -220,20 +220,35 @@
  {{velocity}}
  {{html clean="false"}}
++          <h2 id="interpret-results">4. How to interpret the result</h2>
++
            <p>
--            Use the result as a starting point. Each page should be reviewed in context: why local rights were added, which
--            users or groups are affected, whether rights apply only to that page or to a hierarchy, and whether the exception
--            is still needed.
++            The result should be treated as a review queue, not as a final answer. Each page should be checked in context:
++            why local rights were added, who is affected, whether the rights apply only to one page or to a hierarchy, and
++            whether the exception is still needed.
            </p>
            <div class="resource-note">
              <p>
--              <strong>Important:</strong> a list of pages with local rights does not tell the full story. You still need to
--              interpret inherited permissions, groups, explicit allow or deny rules, wiki-level rights and sensitive rights
--              such as admin, script or programming.
++              <strong>What this snippet helps you find:</strong> pages where local rights may override the expected inherited
++              model, old restricted areas, project spaces with special access rules and confidential pages that should have
++              a clear owner.
              </p>
            </div>
++          <div class="resource-note">
++            <p>
++              <strong>What this snippet does not tell you:</strong> whether the rights are correct, whether the groups are
++              still valid, whether the users inside those groups still need access, or whether inherited permissions already
++              grant access from a parent page.
++            </p>
++          </div>
++
++          <p>
++            A page appearing in this list is not automatically a problem. It simply means that the page deserves a closer
++            look during the first-pass review.
++          </p>
++
            <div class="resource-inline-cta">
              <p>
                <strong>Not sure where local rights are hidden?</strong>
@@ -240,10 +240,10 @@
                A focused access-rights review can help identify local exceptions, inherited permissions, old groups and
                sensitive rights that should be cleaned up or documented.
              </p>
--            <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request an access review</a>
++            <a class="btn btn-default" href="$xwiki.getURL('contact.WebHome')">Request an access review</a>
            </div>
--          <h2 id="sensitive-rights">4. Pay special attention to sensitive rights</h2>
++          <h2 id="sensitive-rights">5. Review sensitive rights separately</h2>
            <p>
              Not all rights have the same impact. View, comment and edit rights affect content collaboration. Administration,
@@ -293,16 +293,34 @@
              </tbody>
            </table>
--          <h2 id="document-findings">5. Document the findings</h2>
++          <h2 id="common-findings">Common findings during a first review</h2>
            <p>
++            A first-pass review often reveals patterns that are not obvious from normal daily use. These findings do not
++            always mean that the instance is unsafe, but they usually deserve clarification.
++          </p>
++
++          <ul class="resource-checklist">
++            <li>Pages restricted years ago for a project that no longer exists.</li>
++            <li>Groups created for temporary access that still grant view or edit rights.</li>
++            <li>Direct user rights added because creating a proper group felt too heavy at the time.</li>
++            <li>Admin or script rights granted to users who no longer maintain the platform.</li>
++            <li>Restricted spaces without a clear business owner.</li>
++            <li>External users still present in groups after the collaboration ended.</li>
++            <li>Local page rights added to solve an urgent issue, but never reviewed again.</li>
++            <li>Group synchronization from LDAP, SSO, OIDC or SAML that no longer matches the expected wiki access model.</li>
++          </ul>
++
++          <h2 id="document-findings">6. Document findings before changing permissions</h2>
++
++          <p>
              An access-rights review should not end with a few manual changes. The result should be documented so that the
              next administrator understands what was found, what was changed and what still needs attention.
            </p>
            <p>
--            A simple review register can be enough. The goal is to record the affected area, the current access model, the
--            risk, the owner and the recommended action.
++            A simple review register is enough for a first pass. The goal is to record the affected area, the current access
++            model, the concern, the owner and the recommended action.
            </p>
            <table class="table table-bordered table-striped">
@@ -336,11 +336,11 @@
              </tbody>
            </table>
--          <h2 id="review-checklist">XWiki access-rights review checklist</h2>
++          <h2 id="review-checklist">XWiki access-rights first-pass checklist</h2>
            <p>
              A practical review should combine technical checks with governance questions. The following checklist can be
--            used as a starting point before changing permissions in production.
++            used before changing permissions in production.
            </p>
            <ul class="resource-checklist">
@@ -353,7 +353,7 @@
              <li>Review admin, script and programming rights separately.</li>
              <li>Check authentication and group synchronization if LDAP, SSO, OIDC or SAML is used.</li>
              <li>Document findings, owners, risks and recommended actions.</li>
--            <li>Schedule a periodic access-rights review.</li>
++            <li>Only then decide what should be cleaned up, simplified or reviewed with the business owner.</li>
            </ul>
            <h2 id="access-review-faq">XWiki access-rights review FAQ</h2>
@@ -400,14 +400,19 @@
              </p>
            </details>
--          <div class="resource-note">
--            <p>
--              Related resources:
--              <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">why XWiki access rights need a clear governance model</a>,
--              <a href="$xwiki.getURL('resources.xwiki-security-review')">what an XWiki security review should actually include</a>
--              and
--              <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">why regular XWiki upgrades matter</a>.
--            </p>
++          <div class="resource-note related-resources">
++            <p><strong>Related resources:</strong></p>
++            <ul>
++              <li>
++                <a href="$xwiki.getURL('resources.xwiki-access-rights-governance')">Why XWiki access rights need a clear governance model</a>
++              </li>
++              <li>
++                <a href="$xwiki.getURL('resources.xwiki-security-review')">What an XWiki security review should actually include</a>
++              </li>
++              <li>
++                <a href="$xwiki.getURL('resources.why-upgrade-xwiki')">Why regular XWiki upgrades matter</a>
++              </li>
++            </ul>
            </div>
            <div class="resource-cta">