How OpenProject and XWiki integration works and what to confirm first
A team that wants work packages in OpenProject to link to XWiki pages and create new ones is asking for an integration that is not documented as an official feature. No official OpenProject connector for XWiki is documented in the material available to DeployOpen, so the method must be confirmed with OpenProject before scope is set. Treat any plan that assumes a ready-made link field, a page creation button or a sync job as an open question until OpenProject answers it in writing. This section explains which parts can be assembled from documented pieces and which parts need confirmation first.
Sign-in is the part that can be built from documented pieces. OpenProject lists OpenID Connect among its single sign-on options, and its pricing page places single sign-on in the Enterprise features, so the edition you need for OIDC sign-in should be confirmed against current pricing and the version you run. On the XWiki side, the community xwiki-contrib/oidc extension handles OpenID Connect sign-in. Both products should trust the same identity provider, which you operate or select. Confirm that the extension supports the XWiki version you plan to run, since official Docker images are published on stable, long term support and intermediate long term support lines.
Work package links and page creation are a different matter. Nothing in the supplied material establishes that OpenProject can call XWiki to create a page, or that a work package can store and display a link to an XWiki page without custom development. Do not assume OAuth-based page creation, and do not assume that a particular XWiki edition is required for it. Ask OpenProject which mechanism, if any, would carry a link or a create request, which API or hook it uses, which credentials it expects and which OpenProject version added it. Then test that mechanism against the running version in a staging environment before accepting it into scope.
Before a quote is written, collect the facts that change the design. Name the identity provider and its OIDC settings, the XWiki version and database variant (MySQL, PostgreSQL and MariaDB images are published), how XWiki groups map to OpenProject roles, and which spaces may receive links or new pages. Decide who owns any custom code if OpenProject does not provide the feature, and who reviews it after each OpenProject and XWiki upgrade. A written scope should separate sign-in work, any custom link or creation work and testing, so each part can be accepted or dropped on its own evidence.
Ask for the confirmations in writing and keep the decision points visible. The first question for OpenProject is whether a supported connector or API exists for XWiki, and the second is which edition and version it requires. The first question for your own team is whether users can accept a link-only design if page creation is not supported. A short proof of concept with one identity provider, one XWiki instance and a test project will show whether OIDC sign-in and the link path behave as expected before any production rollout is planned.
Prerequisites for an OpenProject and XWiki integration
This integration depends on the right editions, release lines and trust relationships being in place before any configuration begins. The six prerequisites below cover both applications, the identity provider that signs users in, and the network between them. Confirm each item in writing with the team that owns it, because several depend on licensing terms and release lines that change over time.
OpenProject edition and plan
The Community edition is free, but OpenID Connect single sign-on is an Enterprise feature, so OIDC sign-in from OpenProject into XWiki requires an Enterprise plan. Confirm the plan tier and user count against OpenProject's current pricing page before you size the project, since the tier needed for sign-in may differ from the one you use for work packages alone. Decide which user groups will use which edition and record the decision in the design.
Supported OpenProject release and database
Run a currently supported OpenProject release and check its system requirements before you choose a host. Since OpenProject 16.0.0, PostgreSQL 16 or later is the officially supported database, and the pg_trgm, btree_gist and unaccent extensions must be available to the OpenProject database. Confirm that your chosen install method, whether Docker, packages or Kubernetes, supports your operating system. Plan for the release you will run in production and verify it against the release notes.
XWiki release line and Docker image
Choose XWiki from the stable, long term support or intermediate LTS line, and match that choice to how often your team can take upgrades. The official Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. Confirm the current image tags on the official Docker library page at build time, because tags change with each release. Record the database variant in the design so the upgrade path is planned from the start.
XWiki OIDC extension and Pro check
Install the OIDC extension from the xwiki-contrib project at the version that matches your XWiki release, because extension compatibility is tied to the XWiki version. Read the extension's compatibility notes before any XWiki upgrade, since an upgrade may require a newer extension version. Ask XWiki SAS whether any part of the planned integration needs XWiki Pro before you assume it does, and confirm the answer in writing as part of the scope.
Identity provider and OIDC clients
Register OpenProject and XWiki as separate OpenID Connect clients in the same identity provider, each with its own client ID, client secret and redirect URI that matches its public hostname. Confirm that the provider issues the claims each application needs for username and email, and that any group claims match the role mapping you plan. Store client secrets in your secret management system and record who approves changes to redirect URIs, since a wrong redirect URI blocks sign-in to both applications.
Network, DNS and TLS trust
Give each application a stable DNS name and a TLS certificate that both systems trust, including the identity provider's certificate chain. OpenProject must reach XWiki, XWiki must reach OpenProject, and both must reach the identity provider's discovery and token endpoints over the paths used in production. Map the firewall rules and any reverse proxy hops on each path. If you use an internal certificate authority, install its root in each application's trust store and test connections from inside each container as well as from a browser.
What the documentation confirms and what still needs testing
The documentation confirms the building blocks but not the integration path itself. OpenProject Enterprise lists OpenID Connect single sign-on among its features, so identity can be handled by OpenProject's login layer. The XWiki OIDC extension is published on GitHub under the xwiki-contrib organization, which gives the team a starting point for the XWiki side. XWiki also publishes official Docker images in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat for amd64 and arm64v8, maintained by the XWiki Core Dev Team. Those facts make a container-based test environment practical, but they do not show how the two products talk to each other.
Several points are not confirmed by the material available to us. We have not established whether OpenProject ships a native XWiki connector, which API calls it would use to create or link wiki pages, or whether an XWiki Pro add-on is required for the behavior you want. Each answer changes the design. A native connector would shift effort toward configuration and upgrades. Without one, the team would own the code that creates or links pages, along with its failure handling and its maintenance after each release of either product. Treat these as open questions until the vendors answer them in writing.
Before you commit to a design, request the connector documentation for your exact OpenProject version from OpenProject, and ask XWiki SAS whether the OIDC extension is supported on the XWiki line you plan to run. XWiki currently publishes stable, long term support and intermediate LTS lines, so pick one line deliberately and confirm extension compatibility with it. Then run a proof of concept that covers linking a work package to an existing page, creating a page from a work package, signing in as a non-administrator, and removing a user's access. Record which steps needed custom code. That record is the most reliable input to a fixed-scope estimate.
Licensing affects cost in a different way from the technical questions. OpenProject lists Enterprise pricing per named user per month on its pricing page: Basic at 5.95 euros, Professional at 10.95 euros with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users. Confirm which tier your login model requires, because single sign-on sits in the Enterprise feature set and the tier may depend on your user count. On the XWiki side, Pro and support subscriptions are tiered by user count, and XWiki SAS states that cloud and on-premises pricing is the same. Ask for both licenses to be quoted against the same user figure.
Configuration sequence for OpenProject and XWiki
This sequence takes XWiki and OpenProject from separate installations to a tested link between work packages and wiki pages. Each step ends with a check you can run yourself, so the sequence doubles as a go or no-go record. Confirm edition, plan and extension requirements with each vendor before you build.
Deploy XWiki from the official image
Deploy XWiki from the official Docker image, which the XWiki Core Dev Team maintains in MySQL, PostgreSQL and MariaDB variants running on Tomcat. Choose the stable, long term support or intermediate LTS line deliberately. The official tags currently include 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS, so confirm the current tags before you pin one. Run the container on infrastructure you control and place its database under your standard backup policy. This step is done when an administrator signs in from a clean browser session and reaches the admin area.
Install and configure the OIDC extension
Install xwiki-contrib/oidc, the community OpenID Connect extension for XWiki, and point it at your identity provider's discovery endpoint, client ID and client secret. Map the claims XWiki needs for user name and email, and decide whether accounts are created on first sign-in. Store the client secret in your secrets store and never on a wiki page. Check: sign in as a test user from a clean browser session, confirm XWiki shows that user's profile, and confirm the identity provider log records the authorization request.
Configure OpenProject sign-in with OIDC
Configure OpenProject to sign in through the same identity provider. OpenProject lists OIDC among its Enterprise single sign-on options, so confirm with OpenProject which plan covers it before you build. Register OpenProject as a client in the provider, set the redirect URI to your OpenProject host, and use the same user identifier claim you chose for XWiki so accounts match later. Check: sign in to OpenProject with a non-administrator test account from a clean browser session, then confirm the identity matches the account used in XWiki.
Decide the linking method with each vendor
Choose how work packages and wiki pages will connect: either a documented connector or a custom integration built on the APIs both systems expose. Confirm the choice in writing with OpenProject and XWiki SAS, including which OpenProject plan and which XWiki Pro extensions the method requires. Do not assume a connector exists because the two products are often deployed together. Check: a written reply from each vendor names the method, the required editions and any extensions, and that reply is filed with the project record before build work starts.
Map identifiers and test one link
Define how each OpenProject work package identifier maps to an XWiki page, including the naming convention, the project key and where the reference is stored. Build the link in a non-production environment only, using one test work package and one test page. Confirm the mapping with a small set of records before you apply it to live projects. Check: the link is visible on the test work package, opens the correct page from a clean browser session, and the reverse reference appears on the page if your chosen method provides one.
Test page creation from work packages
Test page creation from a work package only if the method confirmed in the previous step documents it. If it is documented, create a page from a test work package in the non-production environment, confirm the page lands in the intended XWiki space, and confirm it inherits the permissions you expect for the test user. Record the steps for operators. If creation is not documented, keep it manual and record that decision. Check: either a page created from the work package appears in the correct space with the expected permissions, or the written decision that creation stays manual is filed with the project record.
Review logs and permissions
Review audit and application logs in both systems for the test sign-ins, link creation and any page creation. Then test permissions with at least two accounts: one that belongs to a project and one that does not, confirming each sees only the work packages and pages their role allows. Record which OpenProject roles map to which XWiki groups. Check: the logs show each test event with the expected user, and both accounts see only the work packages and pages their roles permit.
How user identity and work package data map between the systems
This table compares each OpenProject object with its counterpart in XWiki, the source of the value, who owns the mapping and how to check it. Treat every row as a starting design to validate in a test environment, not as a documented field list, because claim names and XWiki extension behavior depend on your identity provider and the versions you deploy. Confirm each row before any user or page data moves between the systems.
| Data item | Planned mapping | Mapping owner | Validation step |
|---|---|---|---|
| User login | OpenProject login maps to the XWiki user name for accounts provisioned through OIDC, using the subject or preferred username claim you confirm with the identity provider | Identity administrator with the XWiki administrator | Sign in as a test user in each system and confirm both accounts resolve to one identity without duplicates |
| User email | OpenProject email maps to the XWiki email field from the email claim, which must be confirmed as present and verified in your identity provider | Identity administrator | Compare the email values for three test users across both systems and confirm notification addresses are correct |
| Display name | OpenProject first and last name map to the XWiki first and last name from the name claims, with the claim names confirmed before the first login | XWiki administrator | Check that page author and history entries show the expected person name for test edits |
| Group membership | OpenProject groups map to XWiki groups only through a claim you confirm the identity provider can send, and any group sync is tested before use | Identity administrator with the platform owner | Log in as members of two test groups and confirm XWiki group membership matches the intended OpenProject groups |
| Project to space | Each OpenProject project maps to an XWiki space with a naming rule agreed in advance, since project names may change after creation | Project management office with the XWiki administrator | Create one test project and confirm the matching space is created or linked with the agreed name |
| Work package identifier to page reference | Work package IDs map to a stable page reference inside the linked space so links remain valid if titles change | Platform owner building the integration | Create a test work package, link a page, rename the work package and confirm the link still resolves |
| Role to group and rights | OpenProject roles map to XWiki groups with rights granted per space, and each mapping is reviewed against the least privilege the team needs | Security or access governance lead | Review a permission matrix for one project and test a read-only and an editing account in XWiki |
| Removed or deactivated users | Deactivation in the identity provider should block XWiki access and remove project roles in OpenProject, and the expected timing must be confirmed | Identity administrator | Disable a test account and confirm sign-in fails in both systems and project access is revoked |
Securing the OpenProject and XWiki connection
Linking OpenProject and XWiki creates a trust path between two systems that each hold their own identities, secrets and access rules. The controls below cover how the OAuth link is configured, how traffic and credentials are protected, and how page access follows people as they join and leave projects.
Client secret storage
The OAuth client secret that OpenProject uses with XWiki is the credential that establishes trust between the two systems. Store it in a secrets manager or a restricted configuration source, not in a repository, a ticket or a shared environment file. Confirm who can read the value, how it is rotated, and whether rotation requires restarting OpenProject or XWiki. Record a named rotation owner before go-live.
Redirect URI restriction
The OAuth provider should accept callbacks only for the exact redirect URIs of each environment, such as production and test instances. Wildcard or open-ended patterns widen the set of places an authorization code can be sent. Keep separate client registrations for each environment, and recheck the registered URI after any hostname, proxy or certificate change, since a mismatch either breaks sign-in or leaves the link more exposed than intended.
TLS everywhere
Serve both OpenProject and XWiki only over HTTPS, including browser redirects, server-to-server token and profile requests, and any internal calls between the two. Use certificates from a certificate authority that both hosts trust, and confirm that certificate validation stays enabled for internal endpoints. Review reverse proxies, load balancers and any custom CA bundle in the container images, because one plaintext hop undermines the whole link.
Least-privilege service identity
If the link uses a service account to create or update XWiki pages from work packages, it needs rights only in the spaces where those pages are written, not site administration. Give it a dedicated identity with no shared login, and apply the same password or key policy you use for other service accounts. Document which spaces it can write to, and review that list each time a new project is onboarded.
Group-based access and offboarding
XWiki's own permission model decides who can see a page, and OpenProject does not enforce XWiki rights. Map XWiki groups to OpenProject project membership so that a linked page is visible only to people who can see the work package. Confirm this behavior with a test user who has no project role. For offboarding, removing a user from OpenProject should also remove their XWiki group membership, so verify that deprovisioning reaches both systems and that existing sessions end.
Audit logging on both sides
Link activity leaves evidence in two systems: OpenProject records work package changes and OAuth activity, and XWiki keeps page history and its own access records. Confirm which events each product logs for OAuth sign-in and page creation, how long each log is retained, and who can read it. Forward both to your central log platform with the user identity intact, then test that a page created from a work package can be traced to the person, the service identity and the time.
Common failures in OpenProject and XWiki integrations and how to fix them
This table lists the failures this integration is most likely to show, with the probable cause and fix for each. Each row names the first log or setting to check, so you can narrow the problem before changing configuration. Work through identity and certificate issues first, because they block sign-in and can hide the other failures.
| Failure | Likely cause | Fix and first check |
|---|---|---|
| Redirect URI mismatch at the identity provider | The callback URL registered for the OpenProject or XWiki client differs from the one the application sends, often in scheme, host, port or path. | Register the exact callback URL for each application and match the host and scheme. First check the identity provider's error for the authorization request. |
| Certificate trust errors between the applications | The XWiki server or OpenProject server does not trust the certificate authority that issued the other side's certificate, often an internal CA. | Install the internal root CA into the trust store of the calling service and restart it. First check the TLS handshake error in the calling application's log. |
| OIDC claims missing or named differently | The identity provider sends claims such as email or groups under other names, or does not release them to the XWiki client scope. | Map claim names in the XWiki OIDC settings and grant required scopes. First check the ID token from a test sign-in. |
| Users sign in to XWiki without matching rights | Authentication succeeds, but the user's group or identifier matches no XWiki group or rights entry. | Map identity groups to XWiki groups and confirm the user identifier matches. First check the user's group membership in the XWiki admin view. |
| Link works for admins but not members | Work package or XWiki page permissions differ by role, so members lack view rights on the target page or linked space. | Compare the member's OpenProject role and the XWiki rights on the same page. First check the member's role in the project's membership list. |
| OpenProject version change breaks the connector | A new OpenProject release changed the integration behavior or its expected settings, leaving the connector out of step. | Check the release notes for the target version and test on staging first. First check the connector's error after the upgrade. |
| Database extension check fails after an upgrade | OpenProject requires PostgreSQL 16 or later with pg_trgm, btree_gist and unaccent, and the upgraded database lacks one of them. | Confirm the PostgreSQL version and install the three extensions in the OpenProject database. First check the migration output for the named extension. |
Questions buyers ask about OpenProject and XWiki integration
Is there a supported OpenProject connector for XWiki and how do we confirm it?
The integration uses OAuth and an XWiki Pro extension, so confirm both parts before you commit. Check the OpenProject documentation for the exact release you plan to run, then check the XWiki Pro extension list for the XWiki version you plan to run. The XWiki OIDC project on GitHub is a community contrib repository, so treat it as source material to review, not as a vendor support commitment. Ask us to confirm the pairing of OpenProject release, XWiki release and extension version in writing as part of the scope, and record that pairing so the build matches what the vendors document.
What does an OpenProject and XWiki integration cost to run?
The cost has three recurring parts and one one-time part. OpenProject Enterprise is billed per named user per month: Basic at 5.95 euros and Professional at 10.95 euros with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users (OpenProject pricing). XWiki Pro and support tiers are 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 XWiki SAS states that cloud and on-premises pricing is the same (xwiki.com pricing). Consulting is listed at 1200 euros per day and requires a Business or Enterprise support plan, and training at 1500 euros per day (xwiki.com pricing). The one-time cost is the implementation itself. Ask each vendor for current prices, and ask us for a quote that lists each item separately.
What makes the integration effort go up or down?
The biggest driver is identity provider complexity. A single provider with clean group claims is far simpler than several directories, nested groups, or multi-factor rules that differ by user type. The second driver is the number of linked spaces, because each space needs its permission mapping checked against the OpenProject roles that will see the linked pages. Other drivers include the XWiki release line and database variant you choose, how many users and groups must map correctly, whether you run a shared test environment, and how many existing XWiki extensions must stay compatible. Ask for an effort breakdown that shows identity, permissions, testing and cutover as separate line items.
What must our team provide before the integration work starts?
Plan to provide the following before work begins: administrator access to your identity provider so the OAuth client can be registered and claims can be mapped; administrator accounts on the OpenProject Enterprise instance and on the XWiki instance; a set of test users covering each role that will create, edit or view linked pages; and a named contact who can approve changes. You will also need a change window on both systems, network paths between OpenProject, XWiki and the identity provider, valid TLS certificates for each hostname, and a confirmed, restorable backup of both systems before cutover. Your written scope should list each of these items with an owner and a date.
Can our internal team build this integration without an outside partner?
A competent internal team can build it if it has three skills in-house: day-to-day administration of OpenProject, administration of XWiki including its extension model, and hands-on experience with OAuth and your identity provider. The main trade-off is not the first working login. It is the edge cases, such as permission drift between spaces and work packages, token expiry, and the upgrade work that follows when either product releases a new version. Ask yourself who will test each upgrade, who will own the extension versions, and who will respond when group membership stops syncing. If those owners are clear, an internal build is a reasonable choice. If they are not, a fixed-scope engagement with a written list of deliverables may be the better fit for your team.
How does a fixed-scope OpenProject and XWiki engagement begin?
Most DeployOpen engagements are fixed-scope, and the scope is agreed in writing before any work starts. The usual sequence is a discovery call about your identity provider, your OpenProject and XWiki versions, the spaces and projects in scope, and your compliance or change-control needs. We then write a scope that lists deliverables, exclusions, the environments involved, the client-provided items described above, acceptance tests and the timeline agreed for each phase. The quote follows from that written scope, so you can compare it with your internal estimate line by line. DeployOpen is a Chainscore Labs company and does not begin work until both parties have signed the scope.
Which XWiki Docker image variant and release line should we choose?
Choose the release line first, based on how often you want to upgrade and how long you want each line supported. At the time of research, the official Docker tags were 18.8.0 for the stable line, 17.10.14 for the long term support line and 18.4.7 for the intermediate long term support line. Then choose the database variant that matches your operations team: MySQL, PostgreSQL or MariaDB, each running on Tomcat and built for amd64 and arm64v8. The official images are maintained by the XWiki Core Dev Team. Before you pick a line, confirm that the XWiki Pro extensions and the OpenProject connector support it, and confirm the current tags on the library page, because tags change over time.
How DeployOpen scopes and delivers the OpenProject and XWiki integration
DeployOpen scopes the OpenProject and XWiki integration as a written, fixed-scope engagement inside your own infrastructure. The work covers OAuth configuration, the XWiki Pro extension the link depends on, and the OpenProject plan your users need. Each engagement starts with the environment details and access decisions that shape the build. Ongoing support is available as a retainer.
How we scope
- The written scope names the OpenProject and XWiki versions, hosting model and identity provider in use.
- Scope records which work packages must link to wiki pages and which projects are in the first rollout.
- We confirm the OpenProject plan the XWiki link requires with the vendor before the scope is signed.
How we build
- We configure OAuth between OpenProject and XWiki, with client registration and redirect URIs documented.
- We install and configure the XWiki Pro extension the integration needs, tested against your XWiki version.
- Linking and page-creation behavior is tested on a staging copy before it reaches production users.
How we hand over
- Handover includes configuration records for both platforms, the OAuth setup and extension versions.
- Runbooks cover upgrading OpenProject and XWiki without breaking the link, with rollback steps.
- Your administrators receive a walkthrough of linking and creating pages from work packages.
How we support
- Ongoing support can cover OpenProject and XWiki updates, extension compatibility and link troubleshooting.
- Support can include checks after each OpenProject or XWiki release, scoped in writing.
- Changes to the integration are handled as new written scope, so costs and timelines stay visible.
