XWiki and Microsoft Entra ID single sign-on

Microsoft Entra ID decides who authenticates, and XWiki decides what an authenticated user can do. When someone opens the wiki and chooses Entra ID sign-in, the browser is redirected to the Microsoft login page for your tenant. The user signs in there, and any multi-factor or conditional access policies you have configured in Entra ID apply at that point. Entra ID then sends an OpenID Connect response back to the wiki's callback address. The XWiki extension validates that response and, if it is accepted, establishes a wiki session. XWiki never receives the user's Entra ID password, so the extension's trust depends on the tokens it validates and on the app registration it is configured against.

After a successful response, the extension has to connect the identity to a wiki user account. Either it creates a new XWiki profile on first login or it matches the identity to an existing profile. Confirm in the extension documentation exactly how first-login profile creation works and which identity attributes it uses, such as a stable subject identifier, the user's name or the email address. The choice matters. Matching on a mutable attribute such as email can attach a sign-in to the wrong account after a rename or a domain change. Ask the extension maintainers or your integrator to confirm the matching rule, then test it with a fresh test user and a user who already has a wiki account, and inspect each resulting profile.

Signing in does not decide what a user can read or edit. Wiki permissions still come from XWiki's own rights model, which applies rights to wikis, spaces and pages and to users and groups. A newly created account receives whatever rights the wiki grants to logged-in users by default, so review those defaults before go-live, along with any rights granted to guests. If your Entra ID groups are meant to influence access, that happens only through the group handling covered in the group mapping section, and the mapped XWiki groups still need the rights you intend them to carry.

The identity flow also sets expectations for offboarding and session behavior. Disabling a user in Entra ID stops that user from completing new sign-ins, but it does not by itself delete the XWiki profile or end sessions that are already open. Confirm with the extension documentation how long a wiki session lasts and whether the extension checks Entra ID again on later requests. Plan for the answer in your offboarding runbook, so that a leaver's access is closed in both systems and the wiki profile is handled according to your records retention policy.

Group sync is the part of the Entra ID extension most likely to remove access without anyone noticing. According to the XWiki Store documentation for the Microsoft Entra ID OpenID Connect extension, when group sync is enabled the extension checks a user's memberships against Entra ID and removes that user from the mapped XWiki groups when it detects a mismatch. A change made in Entra ID, such as a person leaving a security group or moving to another team, can therefore change what that person can read and edit in the wiki. For leavers, this is the intended outcome. For role changes, it can remove rights the person still needs in the new job, and restoring them may take a second change. Plan for removal in both directions before you enable the feature.

Review the mapping before you enable group sync on a live wiki. Work from a written table of Entra ID groups and the XWiki groups each one feeds, not from memory. For every row, confirm which XWiki rights that group carries on which spaces, who owns the Entra ID group, and who approves changes to it. Look for broad groups, such as all-staff groups or groups whose membership follows a directory attribute that changes often, and for groups that include nested or external members. A mistaken mapping can strip rights from a large number of people at once, or give a group more rights than the team intended. Also confirm how the allowed and forbidden group settings combine with the mapping in the version you run, since those settings decide who can sign in at all.

Pilot the change with one small Entra ID group of test users and one XWiki group that grants rights only on a non-production test space. Run the pilot against a staging copy of the wiki with the same extension version and a copy of the production permission model. Sign in as a test user and confirm the expected group membership. Then remove that user from the Entra ID group and check whether XWiki removes the mapped membership and what happens to access on the test space. Repeat the test for a simulated role change, where the user moves from one mapped group to another. Record each step, the time between the Entra ID change and the XWiki result, and any access that changed unexpectedly before you widen the scope.

Document a rollback before enabling the feature on production. Save the current extension configuration, export the existing XWiki group memberships for the affected spaces, and write the steps to disable group sync and restore the previous memberships. Name the administrators who can make these changes and who must be told if access is removed during a rollout. Confirm with the XWiki Store documentation and your extension version exactly when the check runs, for example at sign-in, on each page request, or on a schedule, and whether it can remove a membership during an active session. Until you have that answer, do not assume how quickly leaver access is removed, and do not treat a removal in Entra ID as proof that the wiki has already stopped access.

Before XWiki goes live with Microsoft Entra ID sign-in, run four access cases against a staging wiki that uses the same app registration, redirect URI and group mappings as production. Each case has a single expected result. Write the expected result down before the test, then record what actually happened, including the account used, the Entra ID group memberships at the time, the XWiki groups shown on the user profile and the timestamp of each step. A test that only confirms someone can sign in proves very little, because the risk sits in the refusals and in the removals. Case one: a test user who belongs to an allowed group signs in through Entra ID and reaches the wiki. Case two: a user who belongs to none of the allowed groups is refused at sign-in and gets no XWiki account or group membership. Case three: a user who is in an allowed group and also in a forbidden group is refused, even though the allowed membership alone would normally grant access. This case matters most, because it tests the precedence rule your forbidden list depends on. Use a test account for each case so one failure does not hide another. Case four tests removal. Start with a test user who is in a mapped group and confirm the matching XWiki group is present. Then remove the user from that Entra ID group, wait for the extension's group sync to run, and confirm the XWiki group membership is gone. Confirm the sync timing in the extension's documentation on the XWiki Store rather than assuming a interval, and schedule your wait accordingly. Also check that an already signed-in session does not keep the removed group membership indefinitely, and record what you observe. Add three checks that apply to every case. First, confirm that any request to the wiki over plain HTTP redirects to HTTPS, since the extension requires an HTTPS wiki. Second, log out and confirm the session ends in XWiki and that a return to a protected page prompts a fresh Entra ID sign-in. Third, for a brand-new allowed user, record which XWiki role the account receives on first login, and confirm that role matches your access policy. If it does not, fix the default before go-live, not after. Keep the results in a dated test log that your security or identity owner signs off. Ask your implementation partner or the extension maintainers to confirm any sync behavior your environment depends on, and keep the log with your change records so you can repeat the same cases after each XWiki or extension upgrade.