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.1 to 1.2

From version 2.12

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

Change comment: There is no comment for this version

To version 2.1

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

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,533 +1,0 @@
--{{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}}