How to set up XWiki SSO with your identity provider
XWiki SSO is set up through either an OpenID Connect extension that trusts your identity provider, or a directory authenticator that checks credentials against LDAP or Active Directory. Either way, the setup itself is the easier part. The hard part is mapping directory groups to XWiki rights so that people land with the access they need, and keeping an administrator login working so that you can still repair the system when the identity provider is misconfigured or unavailable. Plan both before you touch the production configuration. Teams need this when their staff already sign in to a central directory and expect one password, one set of joiner and leaver processes, and one place to revoke access. A self-hosted wiki that keeps its own local accounts creates a second population to manage, and it tends to outlive the people who created it. The sign-in step is not where the difficulty lies. An enabled login form does not handle session lifetime, token expiry, group claims that arrive in a different format than XWiki expects, or users who already exist as local accounts with the same username.
Several of these problems are decisions rather than settings. You need to decide whether an identity provider account is matched to an existing XWiki account by a stable identifier or by username, and what happens to local accounts that were created before SSO was enabled. If you are moving content from Confluence, check whether migrated users and groups already exist in XWiki under names that could collide with directory accounts. Ask the migration owner how users and groups were exported, because the mapping from Confluence identities determines which accounts need to be linked rather than duplicated. The two login paths differ in where trust sits. With OpenID Connect, XWiki redirects users to your identity provider and accepts the identity it returns, so the provider owns authentication and group claims. With an LDAP or Active Directory authenticator, XWiki checks credentials against the directory itself, so the directory schema and bind account become part of your design. Confirm with your identity team which option fits your directory and token policy, and confirm the exact extension version and its compatibility with your XWiki line before you commit to either path.
Before go-live, agree on a break-glass administrator account that does not depend on the identity provider, store its credentials under your normal privileged access controls, and test that it works after SSO is enabled. Test a user who is in no groups, a user in several groups, a user who leaves a group, and a user with an existing local account. Record which claim or attribute carries group membership, how often group changes are picked up, and how long a session survives after a directory account is disabled. These answers drive the rights design described elsewhere on this page, and they are the questions to put to any implementation partner or internal team before work starts.
Which XWiki components handle SSO and directory sync
Single sign-on for XWiki involves more than one component. The servlet container, the database that stores user accounts, an authenticator extension and your directory each play a distinct role, and the choices you make for one affect the others. The cards below set out what each piece does and what to confirm before you commit to a design.
XWiki servlet container and database
XWiki runs on a servlet container and stores user accounts, groups and rights in its database. Official Docker images are published with MySQL, PostgreSQL and MariaDB variants, each running on Tomcat. Whatever authenticator you choose must write to or map onto this local user store, so confirm the database and container combination you plan to run and check how your chosen extension behaves with it.
xwiki-contrib OpenID Connect extension
The xwiki-contrib OpenID Connect extension can authenticate XWiki users against an external OpenID Connect provider. It can also make XWiki act as an OpenID Connect provider itself, which is a different role and needs its own review. Confirm the extension version and the authenticator support against the XWiki line you plan to run, whether stable, LTS or intermediate LTS, before you design the login flow.
LDAP or Active Directory directory
Your directory remains the source of truth for people and group membership in most organizations. XWiki needs a defined path to read those accounts and groups, whether through a directory authenticator or through sync. Decide which directory attributes identify a user, how group membership maps to XWiki groups, and who owns that mapping. Confirm the directory integration options available for your XWiki version before you commit.
XWiki Pro Active Directory and Azure AD SSO
XWiki Pro lists Active Directory and Azure Active Directory SSO applications as a commercial route. This avoids building and maintaining a custom authenticator, but it adds a subscription, a support relationship and a dependency on the Pro release cycle. Ask the vendor which XWiki versions the applications support, which directory features they cover and how they handle group mapping before you compare them with the open-source extension.
Group mapping and rights alignment
Authentication only proves identity. Access to spaces and pages depends on XWiki groups and rights, which must reflect the directory groups your organization already uses. Plan which directory groups become XWiki groups, which are ignored, and how removals in the directory revoke access in XWiki. Test this with a pilot group before opening the wiki to everyone.
Verification of login and deprovisioning
Before go-live, test each path a user can take: first login, returning login, group change, account disablement and session expiry. Check that a user removed from the directory cannot keep editing through a cached XWiki account. Record which component enforces each outcome so that your security and audit teams can trace it. Confirm the authenticator's behavior for each case against the version you deploy.
OpenID Connect or directory login: which path fits your XWiki
This table compares four ways to sign users into XWiki: OpenID Connect with an external provider, LDAP or Active Directory, the Pro Active Directory and Azure AD SSO applications, and a hybrid that keeps local administrator accounts. Read each row across to see the fit, the recurring operational cost and who must hold the directory credentials. The main takeaway is that the choice is driven less by login itself and more by who maintains the extension, the subscription and the group mapping after go-live.
| Option | When it fits | Operational cost | Who owns the credentials |
|---|---|---|---|
| OpenID Connect with an external provider (xwiki-contrib OIDC extension) | Your organization already runs a central identity provider that supports OpenID Connect and serves several applications. | The extension must be retested on each XWiki upgrade. Claim-to-group mapping is designed and maintained by your team. | The identity provider team. XWiki stores no directory passwords for federated users. |
| LDAP or Active Directory authentication | Users and groups live in a directory and XWiki must authenticate against it directly. | A service bind account and directory settings need upkeep. Schema or group changes in the directory require retesting group-based rights. | The directory team owns the bind account. Plan read-only, least-privilege access and scheduled password rotation. |
| XWiki Pro Active Directory and Azure AD SSO applications | You want vendor-supported Active Directory or Azure AD sign-in and already plan an XWiki Pro subscription. | A recurring subscription is required. Confirm with XWiki SAS which tier includes these applications and how upgrades are covered. | The directory team owns the tenant or domain. XWiki SAS support covers the application, not your directory configuration. |
| Hybrid with local administrator accounts | You need break-glass access to the wiki if the identity provider or directory is unavailable. | Local passwords must be stored, rotated and reviewed. Every use should be logged and reported to the owning team. | The wiki team holds the local accounts. Keep them out of daily use and limit them to a small named set. |
Configuring XWiki SSO in a sequence you can verify
This sequence moves XWiki from local accounts to federated sign-in one checkpoint at a time. Each step ends with a result you can observe, such as a login with an expected identity or a denied login for a disabled account, so problems surface in a non-production instance before any user is affected.
Confirm the XWiki line and stack
Record the XWiki line you run (stable or LTS), the servlet container, and the database variant, such as MySQL, PostgreSQL or MariaDB on Tomcat if you use the official images. Record the identity protocol you chose: OpenID Connect, LDAP or Active Directory. Check each choice against the release notes for your XWiki line, because extension compatibility depends on it. Your team owns this record, and DeployOpen can help draft it. Done when every component has a version and a named owner, and the non-production instance starts cleanly on that stack.
Register XWiki as a client
Create an OpenID Connect client, or the equivalent directory application, in your identity provider for the non-production XWiki host. Agree the exact redirect URLs with the wiki owner before you enter them, because a mismatch blocks sign-in. Request only the scopes and claims XWiki needs to populate the username and email fields. Done when the provider issues a client identifier for the test host and a test sign-in reaches the provider's login page.
Install and configure the authenticator
Install the chosen extension or authenticator in the non-production instance. For OpenID Connect, the xwiki-contrib OIDC extension can authenticate XWiki users against an external provider, so confirm it supports your XWiki line before installing. For LDAP or Active Directory, confirm whether your edition includes the connector or whether an extension is required. Record every configuration value as you set it. Done when the instance restarts, the login page offers the federated option, and the saved configuration matches your written record.
Test login with a pilot account
Sign in with a pilot account that belongs to a known group. Confirm the XWiki profile shows the identity you expect, meaning the same username, display name and email as the directory record. Then attempt sign-in with a second pilot account that is disabled in the provider, and confirm XWiki refuses access. Review the logs for both attempts so you know what your monitoring will record after cutover. Done when the successful login lands on the expected identity and the disabled account fails.
Map provider groups to XWiki groups
Map provider groups or claims to XWiki groups, starting with the smallest set the pilot needs. Keep group names stable so later changes do not silently alter rights. Avoid mapping broad directory groups to administrative rights. Review the resulting rights at the wiki level before spaces inherit them, and carry that design into your rights and permissions planning. Done when a pilot user's group membership appears in XWiki's group listing, and a user outside the mapped group cannot open a restricted space.
Keep a local administrator path
Before cutover, keep at least one local XWiki administrator account that does not depend on the identity provider. Store its credentials under your privileged-access process, and limit who can retrieve them. Test that this account signs in while federated login is enabled, because a provider outage should never lock every administrator out. Document who may use the account and the conditions for using it. Done when the local administrator signs in successfully with federation enabled, and the test is recorded so you can repeat it after each change.
Cut over and verify production
Agree the change window with the users and owners who will be affected, then enable federated login on the production instance using the same settings you tested in non-production. Run the pilot login, disabled-account and group mapping checks again against production. Confirm the production identity provider client uses the production redirect URLs you agreed earlier. Done when production sign-in succeeds for pilot accounts, the disabled-account check fails as expected, and the local administrator path still works.
How directory groups become XWiki rights
The mapping layer is the handoff between your identity system and XWiki's own group model. Your identity provider or directory issues group memberships to XWiki as claims or attributes during sign-in, an extension translates those values into XWiki groups, and XWiki then applies rights to those groups through its wiki, space and page model. Each of these three steps can fail independently, so plan and test them as separate pieces. This section covers only the handoff. How the rights themselves are structured and inherited belongs to the rights and permissions guide.
Decide early how groups map to wiki structure. One common approach creates one XWiki group per functional role, such as editors or approvers, and grants those groups access across spaces. Another creates one group per space, which gives space owners more control but multiplies the number of mappings you maintain. Nested directory groups add a further choice: you can flatten them so only direct memberships are mapped, or resolve nesting in the identity provider and send a flat list. The second option keeps XWiki simpler, but it means the identity provider must be configured to emit the transitive membership you expect.
Plan for the edge cases before go-live. Users who belong to no mapped group need a defined outcome, such as a default group with minimal read access or no access at all, and you should confirm how the chosen extension behaves in that case. Removing a user from a directory group should also remove the XWiki group membership at the next sign-in, but whether that happens immediately, at session expiry or only on a full synchronization depends on the extension and the protocol in use. Test a revoked membership end to end, including any active sessions and cached group lists, before you rely on it for access control.
Group names and claim formats are the most common source of silent failures. Directory group identifiers may appear as distinct names, distinguished names or object IDs, and the claim name and format can differ between identity providers and between extension versions. Before you build mappings, confirm with the chosen XWiki extension and your identity provider exactly which claim carries group data, how multi-valued groups are encoded, and whether group names are case sensitive. Record the agreed mapping in a table that both the identity and wiki teams review.
What drives XWiki identity integration effort
This table lists the factors that most change the time and cost of an XWiki identity integration, with a way to keep each one under control. Read it before scoping, because most of these drivers are settled in design decisions made before any configuration starts. Several drivers compound each other, so the largest savings usually come from fixing the group model and the number of identity sources early.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Identity providers or directories | Each provider adds a protocol configuration, attribute mapping, test cases and a failure path to support. Two sources with different user identifiers often need a matching rule. | Confirm the authoritative source for each user population before build. Connect one provider per environment where possible and retire secondary sources in the design. |
| Group count and nesting depth | XWiki rights are assigned to groups, so every directory group that maps to a right must be mapped, tested and documented. Deep nesting makes effective membership harder to predict. | Agree a small group model before build, keyed to roles or spaces the knowledge base needs. Map only the groups that carry XWiki rights and avoid mirroring the whole directory. |
| Existing local XWiki accounts | Accounts created before SSO must be linked to directory identities, or users may end up with duplicate profiles and lost page authorship. | Inventory local accounts first. Decide whether to link, disable or migrate them, and confirm how the chosen SSO extension matches identities on first login. |
| Number of environments | Development, test and production each need their own provider client, redirect addresses, certificates or bind accounts, and test users. Drift between environments is a common source of rework. | Reuse a single provider client per environment with consistent configuration. Keep environment differences in deployment settings rather than in custom code. |
| Login page and claim handling customization | Custom login templates, claim transformations and conditional logic move the work from configuration into code that must be tested and kept through XWiki upgrades. | Limit custom code to attribute mapping that the chosen extension supports. Confirm with the extension maintainers which claims and mappings are supported before promising custom behavior. |
| Compliance evidence needs | Assessors may ask for documented access decisions, group-to-role mappings, change records and proof of deprovisioning. Producing this evidence after go-live takes more effort than capturing it during build. | Record group mappings, configuration baselines and test results as you build. Confirm with your assessor which evidence they expect before scoping the work. |
| Pilot testing with real users | Pilot time depends on how many user populations, roles and edge cases (contractors, leavers, shared accounts) must be exercised. Testing only with administrator accounts misses most access problems. | Pick pilot users from each group that maps to a right. Define exit criteria for login, logout, group changes and deprovisioning before the pilot starts. |
| Vendor support and licensing | Advice from XWiki SAS for LDAP, Active Directory or OpenID Connect work is quoted separately. Its published consulting rate is 1200 EUR per day, which requires a Business or Enterprise support plan, according to the XWiki SAS pricing page. These are vendor list figures, not a DeployOpen quote. | Ask whether your support plan already covers the work. Compare vendor list rates with a fixed-scope written quote that states the assumptions and exclusions. |
Securing SSO secrets, sessions and the administrator fallback
Connecting XWiki to an identity provider or directory adds credentials, trust relationships and login paths that all need controls. The cards below cover where secrets live, how the directory service account is scoped, how traffic is protected, how sessions end, which legacy entry points get closed and how administrators regain access if SSO fails.
Keep the OpenID Connect client secret out of config files
The OpenID Connect client secret and any LDAP or Active Directory bind password should not sit in plain text in XWiki configuration files that get copied into backups, images or version control. Decide with your platform team where these values are injected at runtime, such as an environment variable, a mounted secret or your existing secrets manager. Confirm with the xwiki-contrib OpenID Connect extension and your chosen directory connector which settings they read and how they are loaded, then check that the values never appear in logs or the administration interface.
Scope the directory service account to read-only
XWiki only needs to search users and read group membership to map directory groups to XWiki rights. Create a dedicated service account with read-only access to the required organizational units and no write, password reset or group-modification rights. Ask your directory team to confirm the account cannot be used for interactive login, and set a rotation schedule that your operations process can actually follow. Review the account's permissions again after any directory restructuring.
Enforce TLS on every SSO and directory connection
Three connections carry identity data: browser traffic between users and XWiki, the back-channel from XWiki to the identity provider, and the connection from XWiki to the directory. Each should use TLS with certificates that the XWiki Java runtime trusts, and LDAP should use LDAPS or StartTLS rather than unencrypted binds. Test certificate validation explicitly, including what happens when a certificate expires, because failures here often look like generic login errors.
Set session lifetime and propagate logout
Decide how long an XWiki session may remain valid after a user is disabled or leaves the organization, and align that with your identity provider's session policy. Confirm whether XWiki session expiry and single logout are handled by the chosen extension and how a logout initiated at the identity provider reaches XWiki sessions that are still open. Document the residual window where a session stays active, and test it with a disabled test account before go-live.
Close guest and self-registration paths after SSO
Once SSO is live, review whether guest access, self-registration and any local account creation still allow users in outside the identity provider. Each open path becomes a second way in with different controls. Restrict or disable them in line with your access policy, and confirm which spaces remain readable by anonymous users. The broader hardening guide covers the wider handling of guest access and scripting rights.
Document a break-glass administrator account
If the identity provider, directory or certificate fails, administrators need a way back in. Keep one or more local administrator accounts that are excluded from SSO, protected with a strong, separately stored credential, and tested on a schedule. Record who may use them, under what conditions, and how each use is logged and reviewed. The broader hardening guide covers servlet container and extension auditing, which should be reviewed alongside these controls.
How to test XWiki SSO logins, group mapping and failure modes
Before you switch XWiki to single sign-on for real users, run a fixed set of test cases that cover both the success path and the ways login can go wrong. The point is to prove that every failure denies access and produces a clear, safe error, and that every group maps to the rights you designed. A login that works for a pilot administrator tells you very little about what happens to a contractor whose group was removed last week. Start with a successful login for each user group that will hold rights in the wiki. For each group, sign in through the identity provider and confirm three things: the account is created or matched to the expected XWiki user, the user appears in the XWiki groups derived from the directory groups, and the user can view and edit only the spaces that group is allowed to reach. Check the user profile for the identifier XWiki stored, the group membership page for the expected XWiki groups, and page access by opening restricted spaces as that user. Record the result per group so that a mapping error in one group is easy to trace. Next, test the users who should get nothing. Sign in as a valid directory user who belongs to no mapped group and confirm that the account has no elevated rights and cannot open restricted content. Then disable or remove a test account at the identity provider and attempt a login and an active session. The expected result is a refused login, with no content visible. Where the session continues after disablement, check how long it survives in the XWiki logs and the identity provider's session settings, because the answer depends on token lifetimes you must confirm with the vendor and your own configuration. Test session expiry, bad configuration and outages. Let a session expire and confirm that the next request requires re-authentication and does not show cached pages. Change the redirect URL or client secret in a staging copy and check that the login fails with an error that names no secret or internal address; the XWiki and Tomcat logs should record the failure for the operations team. Stop or block access to the identity provider and confirm that users see a clear message and that guest access stays closed. Finally, verify the administrator fallback path. Confirm that a named local administrator can still sign in when the identity provider is down, that this path is restricted to a small number of accounts, and that its use is logged. Keep the test results as evidence for your change record. Ask your integration partner or internal team to document the exact directory groups, test accounts, expected outcomes and log locations used, and to repeat the full set after any change to the identity provider, group mappings or XWiki version. The extension and protocol details that enable these checks are covered in the OpenID Connect and directory sections of this page.
SSO design for single node, clustered and reverse-proxy deployments
A single XWiki node is the simplest case for SSO. There is one public hostname, one set of callback URLs and one place where sessions live, so the design mostly comes down to getting the external address right and confirming that the identity provider can reach the node over the network path you intend to use. Even here, the wiki's externally visible URL must match what is registered with the identity provider, because a mismatch is one of the most common causes of failed logins.
What to confirm for a single node:
- Callback URLs: the exact redirect URI registered with the identity provider must match the scheme, host, port and path that users see in the browser.
- Forwarded headers: if a load balancer or TLS terminator sits in front of the node, confirm whether it forwards the original host and protocol, and how the servlet container is configured to trust them.
- Session storage: confirm where the servlet container keeps HTTP sessions and whether a restart invalidates them, since this sets user expectations after maintenance windows.
- Directory reachability: confirm the node can open connections to the LDAP or Active Directory servers, or to the OpenID Connect discovery and token endpoints, on the ports and paths your network policy allows.
- Certificate trust: confirm the Java trust store on the node contains the CA chain for the identity provider or directory, including any internal CA.
Close by checking that a test login, a logout and a session expiry all behave as expected from a clean browser before any users are onboarded.
When several XWiki nodes sit behind a reverse proxy, SSO design moves from a single hostname to a shared public address with several backends. Callback URLs must still resolve to the public name, but every node must produce the same redirect and trust the same forwarded headers. Session handling also becomes a design question, since a user's requests may land on any node. Whether sessions are shared, sticky or re-established depends on your proxy and servlet container configuration, and this should be confirmed rather than assumed. The XWiki cluster design itself is covered in the high availability topic.
What to confirm for a clustered deployment:
- Callback URLs: every node must advertise the same public base URL, and the identity provider must have that URL registered, not individual node names.
- Forwarded headers: the proxy must set the original host, protocol and client address consistently, and only trusted proxy addresses should be allowed to set them.
- Session placement: confirm whether the proxy uses sticky sessions, whether sessions are replicated between nodes, and what happens to a login when a node fails.
- Directory reachability: each node needs its own network path to the directory or identity endpoints, so firewall rules and DNS must be checked per node, not just for the proxy.
- Certificate trust: every node's trust store must carry the same CA chain, and certificate rotation must be planned so that nodes are not updated at different times.
After configuration, test login against each node directly and through the proxy, and simulate a single node failure to see how the user session behaves.
In an air-gapped or private network the identity provider is internal, and it is often the only source of identity. Public discovery documents, public certificate authorities and internet-hosted callback services are unavailable, so every endpoint must be reachable inside the isolated network. This model changes the trust chain most of all: certificates usually come from an internal CA, and the trust store of each XWiki node and the identity provider must be managed deliberately. Updates to the identity provider's endpoints or certificates need a documented change path, because they cannot be fetched from outside.
What to confirm for an isolated network:
- Callback URLs: the internal hostname used by users must be resolvable inside the network, and the identity provider must hold the exact URI, including any internal DNS name.
- Forwarded headers: confirm whether any internal proxy is in the path and whether it preserves the original scheme and host, as this affects redirect generation.
- Session placement: sessions stay within the private network, so confirm the storage location and how long sessions last under your security policy.
- Directory reachability: confirm that the LDAP or Active Directory servers or the OpenID Connect provider are reachable from each node without relying on any external service.
- Certificate trust: identify the internal CA, import its chain into each node's trust store, and plan how revocation and renewal are handled without internet access.
Verify the design by testing with the internal CA in place and confirming that no step depends on an external lookup, then record the procedure so future certificate changes can be repeated.
What to monitor, back up, upgrade and document after SSO goes live
Once single sign-on is live, the operations team owns the integration for as long as XWiki runs. The first priority is monitoring. Watch failed logins and failed directory binds separately, because they point to different faults: a spike in failed logins often means a changed client secret, an expired certificate or a redirect URI mismatch on the identity provider side, while failed LDAP or Active Directory binds usually mean the service account password changed, was locked or lost its read permission. Forward authentication logs from the XWiki servlet container and from the identity provider to the same place, so a single incident can be traced across both systems. Set alert thresholds with the people who will respond, and agree in advance who receives them outside business hours.
Group sync needs its own check. After each scheduled or triggered synchronization, confirm that the expected users were created or updated, that users who left the directory lost their access, and that the directory groups named in the mapping table produced the XWiki groups and rights you designed. A sync that completes without errors can still assign nothing if a group distinguished name or claim value changed upstream, so compare counts against a known list of members for a sample of groups each month. Record the results, because they are the evidence an auditor or a security reviewer will ask for.
Credentials need a fixed rotation schedule. Client secrets for the OpenID Connect client, the LDAP or Active Directory bind account and any XWiki-side API or service credentials should each have an owner, a due date and a tested procedure for replacing them without an outage. Where the identity provider supports overlapping secrets, use that window to switch XWiki before the old secret is revoked. Store the values in your secrets manager, never in wiki pages or extension configuration exported to shared folders. Confirm with your identity team which rotation periods your policy requires, since those vary by organization.
Every XWiki upgrade and every identity provider upgrade can change behavior that the SSO extension depends on. Claim names, claim formats, token lifetimes, group attribute encoding and the extension's compatibility with a given XWiki line can all shift. Treat the extension as a dependency to test: deploy the target XWiki version and the target identity provider version to a staging environment, then re-run the full verification set, including login, logout, group mapping, denied access and break-glass login. Check the compatibility notes for the extension version you run before choosing an XWiki line, and do not roll the upgrade to production until the verification set passes. Re-run it after any change to either side, even a minor one.
Backups and documentation close the loop. Back up the XWiki configuration files and extension settings, and back up the database that holds user, group and rights data, on a schedule that matches your recovery objectives. Test restores into an isolated environment, because a backup you have never restored is an assumption. Document the attribute mapping table, the claim contract that states which claims XWiki expects and their formats, the owner of each integration component, and the break-glass procedure for signing in with a local administrator when the identity provider is unavailable. Keep the break-glass credentials sealed, review who holds them, and rehearse the procedure at least once a year, so the people who need it can use it under pressure.
What XWiki SSO costs and how long it takes
What drives the cost of an XWiki SSO integration project?
Scope, the number of identity providers, the group model and testing drive most of the cost. Each identity provider you connect adds configuration, attribute or claim mapping, certificate handling and a test cycle. The group model is the largest open decision: mapping a few flat directory groups costs less to build and verify than nested groups that must map to XWiki spaces and rights. Environments matter too, because a test and production pair doubles the work unless configuration is templated and promoted. One-time costs cover design, build, testing and cutover. Recurring costs appear when you add an identity provider, change group structure or upgrade XWiki and its extensions. Ask any provider for a quote that lists each identity provider, each environment, the group model assumptions, the test users and what is excluded.
Should I use the open-source extension or XWiki Pro SSO applications?
The open-source extension suits teams that will own the code, and XWiki Pro suits teams that want vendor-supported applications. The xwiki-contrib OpenID Connect extension can make XWiki an OpenID Connect provider or authenticate XWiki users against an external OpenID Connect provider. It is community maintained, so you carry testing, version compatibility and security review for each XWiki upgrade. XWiki Pro lists Active Directory and Azure Active Directory SSO applications, and XWiki SAS offers support for XWiki Pro. According to XWiki SAS pricing, Pro and support subscriptions come in Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users), and cloud and on-premises pricing is the same. Confirm with XWiki SAS which applications match your directory and whether your user count fits the tier before you decide.
How long does an XWiki SSO pilot take to complete?
Pilot length depends mostly on how complex your directory is, and no fixed duration fits every organization. A single directory with flat groups and one identity provider is the shortest path. Multiple domains or forests, nested groups, attributes that need transformation, multi-factor policies and external users each add design and test time. The pilot scope also changes the timeline: testing with one application group takes less time than testing every department. Before you commit, ask for a timeline in the written scope that states the directory facts it assumes, such as the number of domains, group nesting depth and the identity provider in use. Ask how the timeline changes if the group model is still open at kickoff. Most DeployOpen engagements are fixed-scope, so the agreed timeline follows the written deliverables.
What access and information do we need to give the SSO team?
The work needs admin access to the identity provider, a directory service account, named test users and one decision owner for the group model. Admin access lets the team register XWiki as an application or configure the directory connection, and it should be scoped to those objects where your identity provider allows it. The directory service account should be read-only with least privilege, and you should confirm with your directory team how its password rotates. Named test users should cover each role that will log in, including at least one administrator and one user who should be denied access. The decision owner settles which directory groups map to XWiki groups and rights, and signs off on that mapping before production. Also plan for certificate trust, redirect addresses and a network path from XWiki to the directory or identity provider. Confirm each item in your own environment before kickoff.
Can our internal IT team set up XWiki SSO without a partner?
Yes, an internal team can do it if it has identity provider administration skills, XWiki administration experience and a test environment to work in. The usual gaps sit on the directory side: nested group resolution, certificate trust, service account permissions and attribute mapping. The cost is staff time, and it recurs when you add an identity provider or change group structure. XWiki SAS lists consulting at 1200 EUR per day, a rate that requires a Business or Enterprise support plan, and training at 1500 EUR per day, according to its pricing page. Those are vendor list rates, and a partner quote will depend on your written scope. Many internal teams choose a split model: they run the identity provider work, and a partner reviews the XWiki configuration and group mapping before cutover. Whichever model you pick, write down who owns each step.
What usually goes wrong with LDAP or Active Directory group mapping?
Most failures come from group resolution, attribute mismatches and certificate trust, and they often appear only after users try to log in. Nested groups may not resolve the way administrators expect, so a user who belongs to a child group can lose rights they should have. The login attribute in the directory may differ from the username XWiki expects, which creates duplicate or orphaned accounts. Secure LDAP connections fail when the certificate chain is not trusted by the Java trust store used by the servlet container. Service account passwords that expire silently cause logins to fail for everyone at once. Users who leave the directory may keep access if deprovisioning is not reflected in XWiki. Test each of these with named accounts before cutover, and confirm the behavior against the XWiki version you run, since configuration details change between releases.
How DeployOpen scopes, builds and hands over XWiki SSO
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and XWiki SSO is handled the same way. We agree the identity provider, protocol and group mapping in writing before work starts, then build and verify the connection in your environment.
How we scope
- Confirm which identity source applies: an OpenID Connect provider, LDAP or Active Directory, and who owns it.
- Agree in writing which directory groups map to which XWiki rights, and who approves that mapping.
- Define the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope.
How we build
- Configure XWiki authentication against the chosen identity source in a test environment before any production change.
- Check the OpenID Connect extension's fit against your provider's claims and your XWiki version before committing to it.
- Test login, logout, group-based rights and access for users who should be denied, using agreed test accounts.
How we hand over
- Document the configuration, group-to-rights mapping, service accounts and the steps for adding or removing a directory group.
- Walk your team through the runbook so they can rotate secrets, troubleshoot login failures and review access changes.
- Record test results and open items so your team and any auditor can trace how identity integration was verified.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
- Plan identity configuration checks again whenever XWiki or the identity provider is upgraded.
- Confirm with your identity provider vendor and XWiki release notes which versions your integration depends on.
