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 2.9 to 2.8

From version 2.8

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

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,477 +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">How to start an XWiki access-rights review</h1>
--
--      <p class="resource-summary">
--        A practical first step for identifying 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="#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="#review-checklist">Checklist</a></li>
--            <li><a href="#access-review-faq">FAQ</a></li>
--          </ul>
--        </aside>
--
--        <article class="resource-content">
--
--          <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> 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.
--            </p>
--          </div>
--
--          <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.
--          </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.
--            </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.
--          </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>
--
--          <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="access-model">1. Start with the access model, not with the UI</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.
--          </p>
--
--          <p>
--            A simple model 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>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.
--          </p>
--
--          <table class="table table-bordered table-striped">
--            <thead>
--              <tr>
--                <th>Group review item</th>
--                <th>What to check</th>
--                <th>Possible 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>
--              </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>
--              </tr>
--              <tr>
--                <td>Unclear group names</td>
--                <td>Groups whose purpose is not obvious</td>
--                <td>Rename, document or consolidate</td>
--              </tr>
--              <tr>
--                <td>Overloaded groups</td>
--                <td>Groups used for 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>
--              </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, but it gives you a practical first list of
--            places where local rights may exist.
--          </p>
--{{/html}}
--{{/velocity}}
--
--{{code}}
--#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 |= Local rights found
--  #foreach ($page in $pages)
--    | [[$page]] | yes
--  #end
--#end
--{{/code}}
--
--{{velocity}}
--{{html clean="false"}}
--          <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.
--          </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.
--            </p>
--          </div>
--
--          <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-primary" href="$xwiki.getURL('contact.WebHome')">Request an access review</a>
--          </div>
--
--          <h2 id="sensitive-rights">4. Pay special attention to sensitive rights</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="document-findings">5. Document the findings</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.
--          </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 review 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.
--          </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>Schedule a periodic access-rights review.</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">
--            <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>
--
--          <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}}