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 1.2 to 2.1

From version 2.1

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

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

@@ -1,0 +1,533 @@
++{{velocity}}
++#set ($discard = $xwiki.ssx.use('PublicWebSite.WebHome'))
++{{html clean="false"}}
++
++  <section class="resource-header" aria-labelledby="hero-title">
++    <div class="container">
++      <div class="text-center">
++        <div class="hero-kicker">
++          <i class="fa fa-search" aria-hidden="true"></i>
++          XWiki access-rights review
++        </div>
++      </div>
++
++      <h1 id="hero-title">A first-pass XWiki access-rights audit before changing permissions</h1>
++
++      <p class="resource-summary">
++        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>
++  </section>
++
++  <section class="resource-page">
++    <div class="container">
++      <div class="resource-layout">
++
++        <aside class="resource-sidebar" aria-label="Page summary">
++          <h4>In this guide</h4>
++          <ul>
++            <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>
++        </aside>
++
++        <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>
++
++          <p>
++            This usually happens slowly. A team needs access, a page is restricted, a group is created, an exception is
++            added, an external user is invited, and after a few years the access model becomes difficult to explain.
++          </p>
++
++          <div class="resource-note">
++            <p>
++              <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>
++            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> 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>
++
++          <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>.
++          </p>
++
++          <h2 id="first-pass-audit">A practical first-pass audit</h2>
++
++          <p>
++            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>
++
++          <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 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 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>
++
++          <table class="table table-bordered table-striped">
++            <thead>
++              <tr>
++                <th>Area type</th>
++                <th>Typical access</th>
++                <th>First review question</th>
++              </tr>
++            </thead>
++            <tbody>
++              <tr>
++                <td>Open internal knowledge</td>
++                <td>Most authenticated users can view, selected users can edit</td>
++                <td>Is this content really safe for broad internal access?</td>
++              </tr>
++              <tr>
++                <td>Team or project spaces</td>
++                <td>Team members can edit, others may only view</td>
++                <td>Are the groups still aligned with the current team?</td>
++              </tr>
++              <tr>
++                <td>Restricted projects</td>
++                <td>Only selected groups can view or edit</td>
++                <td>Is access granted through groups or individual users?</td>
++              </tr>
++              <tr>
++                <td>Confidential documents</td>
++                <td>Small controlled group</td>
++                <td>Who owns the restriction and when was it last reviewed?</td>
++              </tr>
++              <tr>
++                <td>Technical administration pages</td>
++                <td>Trusted administrators only</td>
++                <td>Are admin, script and programming rights limited?</td>
++              </tr>
++            </tbody>
++          </table>
++
++          <h2 id="review-groups">2. Review groups before reviewing pages</h2>
++
++          <p>
++            In most XWiki instances, groups should be the foundation of the permission model. Rights assigned directly to
++            individual users are harder to maintain because people change roles, leave the organization or move between teams.
++          </p>
++
++          <p>
++            Start by reviewing which groups exist, what they are used for and whether their members still match the intended
++            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 signal</th>
++                <th>What it may indicate</th>
++                <th>First action</th>
++              </tr>
++            </thead>
++            <tbody>
++              <tr>
++                <td>Old project groups</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>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>Nobody can easily explain what the group controls</td>
++                <td>Document, rename or consolidate</td>
++              </tr>
++              <tr>
++                <td>Overloaded groups</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>Powerful rights may be granted too broadly</td>
++                <td>Review membership separately</td>
++              </tr>
++            </tbody>
++          </table>
++
++          <h2 id="find-local-rights">3. Identify pages with local access rights</h2>
++
++          <p>
++            Local page-level rights are often where surprises appear. They are useful when a page or page hierarchy needs
++            special access rules, but they can become difficult to manage when they are added repeatedly without documentation.
++          </p>
++
++          <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. It gives you a practical first list of
++            pages where local rights may exist.
++          </p>
++{{/html}}
++{{/velocity}}
++
++{{code language="velocity"}}
++#set ($query = "from doc.object(XWiki.XWikiRights) rights order by doc.fullName asc")
++#set ($pages = $services.query.xwql($query).execute())
++
++#if ($pages.isEmpty())
++  No pages with local XWiki rights were found.
++#else
++  |= Page |= Review note
++  #foreach ($page in $pages)
++    | [[$page]] | Local rights configured
++  #end
++#end
++{{/code}}
++
++{{velocity}}
++{{html clean="false"}}
++          <h2 id="interpret-results">4. How to interpret the result</h2>
++
++          <p>
++            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>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>
++              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-default" href="$xwiki.getURL('contact.WebHome')">Request an access review</a>
++          </div>
++
++          <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,
++            script and programming rights can have a broader technical and security impact and should be reviewed separately.
++          </p>
++
++          <p>
++            A user with powerful rights may be able to change configuration, execute advanced scripts, affect other users or
++            influence how content is rendered. These rights should be granted intentionally, limited to trusted users and
++            documented as part of the administration model.
++          </p>
++
++          <table class="table table-bordered table-striped">
++            <thead>
++              <tr>
++                <th>Right type</th>
++                <th>Why it matters</th>
++                <th>Review approach</th>
++              </tr>
++            </thead>
++            <tbody>
++              <tr>
++                <td>Admin</td>
++                <td>Can control important wiki configuration and rights</td>
++                <td>Keep limited and review membership regularly</td>
++              </tr>
++              <tr>
++                <td>Script</td>
++                <td>Can allow advanced scripting behavior depending on context</td>
++                <td>Grant only to users who understand the technical impact</td>
++              </tr>
++              <tr>
++                <td>Programming</td>
++                <td>Can be highly sensitive and should be reserved for trusted technical administrators</td>
++                <td>Review separately from normal editing permissions</td>
++              </tr>
++              <tr>
++                <td>Edit</td>
++                <td>Allows content changes and may affect business processes</td>
++                <td>Assign through groups and validate restricted areas</td>
++              </tr>
++              <tr>
++                <td>View</td>
++                <td>Controls access to content and confidential information</td>
++                <td>Review public, internal and restricted areas carefully</td>
++              </tr>
++            </tbody>
++          </table>
++
++          <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 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">
++            <thead>
++              <tr>
++                <th>Area or page</th>
++                <th>Current access</th>
++                <th>Risk or concern</th>
++                <th>Recommended action</th>
++                <th>Owner</th>
++                <th>Review date</th>
++              </tr>
++            </thead>
++            <tbody>
++              <tr>
++                <td>Example.ProjectSpace</td>
++                <td>Old project group can still view</td>
++                <td>Project ended, access may no longer be needed</td>
++                <td>Confirm owner and remove group if obsolete</td>
++                <td>Project owner</td>
++                <td>YYYY-MM-DD</td>
++              </tr>
++              <tr>
++                <td>Example.ConfidentialDocs</td>
++                <td>Individual users have direct rights</td>
++                <td>Difficult to maintain when roles change</td>
++                <td>Move access to a dedicated group</td>
++                <td>Content owner</td>
++                <td>YYYY-MM-DD</td>
++              </tr>
++            </tbody>
++          </table>
++
++          <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 before changing permissions in production.
++          </p>
++
++          <ul class="resource-checklist">
++            <li>Identify public, internal, restricted and administrative areas.</li>
++            <li>List active groups and clarify what each group is used for.</li>
++            <li>Review old groups, inactive users and temporary access.</li>
++            <li>Identify pages with local XWiki rights objects.</li>
++            <li>Review page-level exceptions and inherited permissions.</li>
++            <li>Check whether rights are assigned to groups rather than individual users.</li>
++            <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>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>
++
++          <details class="resource-faq-item" open>
++            <summary>Is listing pages with local rights enough for an access audit?</summary>
++            <p>
++              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.
++            </p>
++          </details>
++
++          <details class="resource-faq-item">
++            <summary>Should XWiki rights be assigned directly to users?</summary>
++            <p>
++              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.
++            </p>
++          </details>
++
++          <details class="resource-faq-item">
++            <summary>What is the most common access-rights problem in XWiki?</summary>
++            <p>
++              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.
++            </p>
++          </details>
++
++          <details class="resource-faq-item">
++            <summary>Should access rights be reviewed before an XWiki upgrade?</summary>
++            <p>
++              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.
++            </p>
++          </details>
++
++          <details class="resource-faq-item">
++            <summary>Does SSO replace an access-rights review?</summary>
++            <p>
++              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.
++            </p>
++          </details>
++
++          <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">
++            <h3>Need help reviewing XWiki access rights?</h3>
++            <p>
++              If your XWiki instance has grown over time, uses many groups, contains restricted areas or depends on LDAP,
++              SSO, OIDC or SAML, an access-rights review can help identify unclear permissions and define a safer model.
++            </p>
++            <a class="btn btn-primary" href="$xwiki.getURL('contact.WebHome')">Request an access-rights review</a>
++          </div>
++
++        </article>
++      </div>
++    </div>
++  </section>
++
++  <script type="application/ld+json">
++  {
++    "@context": "https://schema.org",
++    "@type": "FAQPage",
++    "mainEntity": [
++      {
++        "@type": "Question",
++        "name": "Is listing pages with local rights enough for an access audit?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "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."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "Should XWiki rights be assigned directly to users?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "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."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "What is the most common access-rights problem in XWiki?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "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."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "Should access rights be reviewed before an XWiki upgrade?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "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."
++        }
++      },
++      {
++        "@type": "Question",
++        "name": "Does SSO replace an access-rights review?",
++        "acceptedAnswer": {
++          "@type": "Answer",
++          "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."
++        }
++      }
++    ]
++  }
++  </script>
++
++{{/html}}
++{{/velocity}}