Changes for page XWiki Two-Factor Authentication

Last modified by Agnease on 2026/05/23 18:56

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

From 1.11 to 1.12 From 1.15 to 1.16

From version 1.12

edited by Agnease
on 2026/05/22 03:35

Change comment: There is no comment for this version

To version 1.15

edited by Agnease
on 2026/05/22 03:46

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -35,20 +35,21 @@
          <h2 id="overview-title">Stronger login protection for XWiki</h2>
          <p>
--          The XWiki Two-Factor Authentication extension adds an additional verification screen after the standard
--          username and password login. Users confirm their identity with a time-based one-time code generated by an
--          authenticator app, or with a verification code delivered by email.
++          The XWiki MFA / Two-Factor Authentication extension adds additional verification after the standard
++          XWiki username and password login. It strengthens account protection without replacing the familiar
++          XWiki authentication flow.
          </p>
          <p>
--          The extension is designed for organizations that want to improve account security while keeping authentication
--          close to the standard XWiki login experience. It also supports remembering trusted clients beyond the current
--          session, so users are not forced to enter a second factor again on every login from the same trusted browser.
++          The extension supports authenticator app codes using TOTP, email-delivered one-time verification codes,
++          and stricter configurations where both verification methods are required. This allows organizations to
++          choose between a simpler 2FA setup or a stronger multi-step MFA policy.
          </p>
          <p>
--          It can be useful for internal knowledge bases, intranets, documentation platforms, SOP systems, or other
--          XWiki environments where access to content and administration should be better protected.
++          Trusted clients can also be remembered for a configured period. In practice, this means that a known
++          browser or device can avoid repeated MFA prompts, while new or untrusted clients still require the
++          configured verification steps.
          </p>
        </article>
@@ -56,12 +56,11 @@
          <h3 id="quick-facts-title">Quick facts</h3>
          <ul>
            <li>Works with the standard XWiki login flow</li>
--          <li>Supports authenticator app verification codes</li>
--          <li>Supports email-delivered verification codes</li>
--          <li>Can remember trusted clients beyond the current session</li>
--          <li>Configuration available from wiki administration</li>
--          <li>User setup available during login or from the user profile</li>
--          <li>Administrators can enable, disable or reset MFA for users</li>
++          <li>Supports authenticator app codes using TOTP</li>
++          <li>Supports email-delivered one-time verification codes</li>
++          <li>Can require app code and email code together for stricter MFA</li>
++          <li>Can remember trusted browsers or devices beyond the current session</li>
++          <li>Includes wiki administration and user profile controls</li>
            <li>Can be used on the main wiki and subwikis</li>
          </ul>
        </aside>
@@ -95,7 +95,7 @@
          </div>
          <h3>Authenticator app codes</h3>
          <p>
--          Users can verify access with codes generated by authenticator applications, such as mobile TOTP apps.
++          Users can verify access with TOTP codes generated by authenticator applications on a mobile device or desktop.
          </p>
        </article>
@@ -105,12 +105,22 @@
          </div>
          <h3>Email verification codes</h3>
          <p>
--          Users can also receive a verification code by email, useful when an authenticator app is not available.
++          Users can receive one-time verification codes by email, useful when an authenticator app is not available or preferred.
          </p>
        </article>
        <article class="product-feature">
          <div class="feature-icon">
++          <i class="fa fa-plus-circle" aria-hidden="true"></i>
++        </div>
++        <h3>Combined verification</h3>
++        <p>
++          The extension can also require both an authenticator app code and an email code for stricter multi-factor verification.
++        </p>
++      </article>
++
++      <article class="product-feature">
++        <div class="feature-icon">
            <i class="fa fa-qrcode" aria-hidden="true"></i>
          </div>
          <h3>User setup screen</h3>
@@ -121,12 +121,11 @@
        <article class="product-feature">
          <div class="feature-icon">
--          <i class="fa fa-clock-o" aria-hidden="true"></i>
++          <i class="fa fa-laptop" aria-hidden="true"></i>
          </div>
          <h3>Remember trusted clients</h3>
          <p>
--          Trusted browsers can be remembered beyond the current session, reducing repeated MFA prompts while keeping
--          the second factor active for new or untrusted clients.
++          Known browsers or devices can be remembered for a configured period, reducing repeated MFA prompts from trusted clients.
          </p>
        </article>
@@ -136,7 +136,7 @@
          </div>
          <h3>Administration controls</h3>
          <p>
--          Administrators can enable the feature globally, manage user-level activation, and reset a user setup when required.
++          Administrators can configure MFA behavior, manage user activation, and reset user setup when required.
          </p>
        </article>
@@ -217,18 +217,22 @@
          <h2 id="compliance-title">Useful for MFA adoption and NIS 2 readiness</h2>
          <p>
--          Many organizations now need multi-factor authentication for enterprise software, especially when the
--          platform contains internal documentation, procedures, operational knowledge or sensitive business data.
++          Many organizations now need multi-factor authentication for enterprise software, including internal
++          knowledge bases, documentation platforms, intranets and systems that contain operational procedures
++          or sensitive business information.
          </p>
          <p>
--          For organizations using XWiki as a knowledge platform, having MFA embedded in the standard XWiki login
--          experience helps close a practical security gap without requiring a full replacement of the authentication flow.
++          For organizations using XWiki, adding MFA directly to the standard XWiki login flow can help close a
++          practical access-control gap. The extension can support simple 2FA with one additional verification method,
++          or a stricter MFA setup where both authenticator app and email verification are required.
          </p>
          <p>
--          This can be relevant for companies preparing for NIS 2 requirements, where MFA is part of a broader
--          cybersecurity risk management and access protection strategy.
++          This can be relevant for organizations preparing for NIS 2, where multi-factor authentication or
++          continuous authentication is part of cybersecurity risk-management measures, where appropriate.
++          MFA support in XWiki is only one part of a broader compliance and security program, but it can be an
++          important technical control for protecting access to the wiki.
          </p>
        </article>