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 2.4 to 2.5

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.4

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

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,474 @@
++{{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}}
++{{code language="velocity"}}
++#set ($query = "select distinct doc.fullName from XWikiDocument doc, BaseObject obj where obj.name = doc.fullName and obj.className = 'XWiki.XWikiRights' 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}}
++
++{{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}}