Collabora Online and ILIAS integration

Collabora Online and ILIAS integration: what it changes for course documents

This integration uses the WOPI protocol, with ILIAS acting as the WOPI host that stores and serves the document and a self-hosted Collabora Online server acting as the editor that renders it in the browser. The exact ILIAS settings that enable WOPI and point ILIAS at the Collabora discovery URL must be confirmed against the ILIAS release you run, because support for this path depends on the release and its configuration. Do not assume a particular ILIAS version supports it until you have checked the ILIAS documentation and tested it in a staging instance.

For learners and instructors, the change is in how a file opens. Selecting an office file in the repository hands it to the external editor in a browser tab instead of downloading it for local work. Storage, folder structure, object permissions and course roles stay inside ILIAS, so the editor reads and writes through ILIAS rather than managing access on its own. Before rollout, confirm which file types open in the editor on your release, whether saved changes create new versions in the repository, and how ILIAS behaves when a user without edit rights opens a document. Test those three cases with a course instructor, a learner and a read-only role.

What you need before enabling WOPI in ILIAS

Enabling Collabora Online in ILIAS touches the learning platform, the editor server, the network and the people who will run both. The cards below cover what to settle before changing any WOPI or editor setting, so the test instance and the production rollout start from the same decisions.

Confirm the ILIAS release and version range

Identify the exact ILIAS release you run and check its documentation for WOPI or editor settings. Then confirm with ILIAS and Collabora which Collabora Online version range supports that release, since the compatibility matrix is not something to assume. Check Collabora's integration documentation for ILIAS before any purchase decision, including whether the support tier you need is covered.

A Collabora Online server reachable from both sides

The Collabora Online server must be reachable from ILIAS over the network, and users' browsers must reach it directly as well, because the editor loads inside the browser. Map the paths from the ILIAS application servers, from the internet or campus network where users sit, and through any reverse proxy or firewall in between. Decide whether the server runs on Linux packages, Docker or Kubernetes in the infrastructure you control.

Valid TLS and matching protocols

Use a valid TLS certificate on the Collabora Online server and make sure the ILIAS side and the editor URL use the same protocol, preferably HTTPS. Mixed HTTP and HTTPS settings are a common cause of blocked editing sessions. Confirm that the certificate chain is trusted by the ILIAS servers and by student and staff browsers, and plan renewal before it expires.

An agreed hostname and discovery URL

Fix the public hostname of the Collabora Online server and the discovery URL that ILIAS will use before configuration starts. Changing the hostname later means updating the discovery URL, the WOPI host allow list and any certificates that name the host. Record the exact values in your configuration documentation so the test and production instances match.

A test ILIAS instance

Prepare a separate ILIAS instance that mirrors production in release, plugins and authentication. Use it to enable WOPI, open repository documents in the external editor and check that saves, permissions and file formats behave as expected. Keep test documents that contain no real learner data, and confirm that the test environment can reach the same Collabora Online version you plan to run in production.

A named owner for the editor

Assign one person or team to own the Collabora Online connection, including configuration changes, certificate renewals, Collabora Online updates and the response when editing fails. Ownership should be written down and include who handles ILIAS settings and who handles the Collabora server, since the two often sit with different teams. Without a named owner, the first failed save usually becomes a dispute between them.

Configuring Collabora Online and ILIAS in the right order

This sequence takes an ILIAS installation from its current editor settings to Collabora Online editing for a limited group of users, with a check at each stage so that a fault is found before it reaches the full user base.

Confirm the ILIAS release and editor settings
The ILIAS administrator records the installed ILIAS release and reviews the existing file editing and WOPI-related settings in the administration area. Check the ILIAS documentation for the exact menu names for the external editor and discovery URL, because these depend on the release. Record the current state so the change can be reverted. The step is done when the release number and the current settings are written down and the menu path for the discovery URL is confirmed against the ILIAS documentation for that release.
Deploy or verify the Collabora Online server
The infrastructure team confirms that a Collabora Online server is running in infrastructure you control, or deploys one using the Docker images, system packages or Kubernetes options described in Collabora's product documentation. The server needs a stable public URL with HTTPS, and ILIAS must be able to reach it over the network. Check that the server's public address matches the address you plan to give ILIAS. The step is done when the server responds on its public URL and the URL is documented.
Set the discovery URL in ILIAS
An ILIAS administrator enters the Collabora Online discovery URL in the external editor settings, using the same protocol and host name that the Collabora server presents. Save the change and keep the previous value available for rollback. Confirm that the value matches the URL you tested in the previous step. The step is done when the setting is saved and the ILIAS administration page shows the new value without an error.
Restrict WOPI requests to known Collabora addresses
The platform administrator limits WOPI requests so that only the Collabora server addresses can reach the ILIAS endpoints, where the platform and network setup allow it. Nextcloud's administration manual recommends this kind of restriction and the same protocol for both sides, preferably HTTPS. Confirm whether ILIAS offers an allow list setting for WOPI hosts in your release, and if it does not, document the network control you use instead. The step is done when a request from an address outside the list is refused and a request from the Collabora server still succeeds.
Assign which groups may open and edit
The ILIAS administrator decides which roles or groups may open documents in the external editor and which may edit them rather than only view them. Start with a small, named group of trusted users. Check the ILIAS documentation for the permission names that control viewing and editing in this release. The step is done when a user outside the group cannot open the editor and a user inside the group sees the expected view or edit mode.
Test with one repository file
A test user opens one non-sensitive document from the ILIAS repository in read-only mode, confirming that the document loads and the discovery connection works. The same user then makes a small, recognizable edit and confirms the change saves back to the same repository object. Reopen the file in a second session to verify the saved content. Note any format warnings. The step is done when the read-only open, the edit and the save-back all succeed and the saved version matches what was edited.
Widen access in controlled stages
After the test passes, the administrator extends the editing permissions to additional groups in stages, checking each stage with a representative user before the next. Keep a record of each permission change and the date it was made. Review the Collabora Online release notes for any advisories that apply to the version in use before widening access. The step is done when each added group has been verified and the full permission set is recorded.

Mapping ILIAS users, roles and repository objects to editor access

This table compares each ILIAS identity or object with the editor role or setting it maps to, who controls it, and what to verify before opening the editor to users. Read it top to bottom as a checklist, because the editor only grants what ILIAS already allows the user to see and change in the repository. Confirm every exact role and setting name in your own installation before you map anything.

ILIAS object or identity	Editor role or setting it maps to	Who controls it	What to verify
Learner accounts	Viewing access to a document through the editor, if the user already has read permission on the file	Platform administrator and course or group owner	Log in as a test learner, open a shared file and confirm the editor loads in view mode only
Instructor accounts	Editing access, if the instructor holds write permission on the repository object and the editor-use and edit-rights settings allow it	Platform administrator, with course staff assigning roles	Confirm the instructor can open and save changes, and that the saved version appears back in the repository
Course or group membership	Inherited access to documents in the course or group folder, based on the membership role	Course or group administrator	Check that a learner removed from the course loses editor access to course files on the next session
Repository file permissions	The ceiling for everything above: a user cannot edit in the editor what ILIAS does not let them write	Repository object owner and administrators	Test read and write permissions on sample files with each role, including files inside nested folders
Editor-use group setting	Controls which groups may open documents in the external editor at all	Platform administrator	Confirm the exact setting name in your installation and test with a group that is excluded
Edit-rights group setting	Controls which groups may edit rather than only view documents opened in the editor	Platform administrator	Test one group allowed to view only and one allowed to edit, and confirm the editor enforces the difference
File types the editor will open	Only the formats the Collabora Online server accepts, such as OpenDocument and Microsoft formats like docx, xlsx and pptx	Platform administrator and Collabora server configuration	Upload a sample of each format used in your courses and confirm it opens and saves without loss

Why education records change the access design

For a US institution, the access design for Collabora Online inside ILIAS starts from a legal fact: FERPA applies to any educational agency or institution that has received funds under a program administered by the US Secretary of Education (34 CFR 99.1). Once ILIAS holds course files, assessments or learner submissions that contain personally identifiable information from education records, the editor becomes part of that protected flow. An outside party, including a hosted or contracted editing service, may receive those records as a school official only if it performs a service the institution would otherwise perform with employees, is under the institution's direct control for the use and maintenance of the records, and follows the redisclosure limits in 34 CFR 99.33(a) (34 CFR 99.31(a)(1)(i)(B)). Confirm with your counsel whether your self-hosted Collabora server and its operator meet those conditions in your contract and operating model.

The institution must also use reasonable methods, such as technological access controls, so that school officials see only the education records in which they have a legitimate educational interest (34 CFR 99.31(a)(1)(ii)). In practice, this means the people who can open a document in the external editor should be limited by ILIAS roles and course membership, and the WOPI access decisions should follow the same boundaries. Test this with real course structures before rollout, using a test course and a test learner account, and record which roles can open, view and edit each file type. FERPA also requires a record of each request for access to and each disclosure of personally identifiable information, with the parties involved and their legitimate interests, kept for as long as the records are kept (34 CFR 99.32). Decide early which component produces those records, such as ILIAS logs, WOPI host logs or the Collabora server logs, and confirm that they can be retained and retrieved.

Two other rules may apply depending on your population and funding. If learners under 13 are included and the editor or ILIAS collects their personal information, the COPPA Rule (16 CFR Part 312) may apply, including its requirements for a written information security program and a written data retention policy. Institutions in the Title IV federal student aid programs have agreed to meet the GLBA Safeguards Rule (16 CFR Part 314), which expects a written information security program and multi-factor authentication for anyone accessing an information system. This section is a planning input, not legal advice. Ask counsel to confirm the institution's position on each rule before you finalize roles, logging and retention for the Collabora integration.

Single server or Kubernetes: how the editor deployment changes the work

A single Collabora Online server is the simplest model for an ILIAS installation with a modest number of editors. You deploy it from Docker images or from system packages, and ILIAS reaches one hostname for the discovery URL and for every WOPI request. Because there is one endpoint, the WOPI host configuration, the TLS certificate and the firewall rules all point at the same place, which keeps the number of moving parts low.

One endpoint: ILIAS, the browsers of editing users and the Collabora server all refer to a single base URL, so DNS and reverse proxy rules stay short.
Manual certificate handling: You issue, install and renew the TLS certificate yourself, typically on the reverse proxy in front of the server. Confirm who owns that renewal task before go-live.
Simpler troubleshooting: Logs, process state and connectivity checks all live on one host, so a failed document open is usually traced in one place.
Vertical capacity only: Extra capacity means a larger machine or a second, separately configured server, not automatic replicas. Plan for this when user numbers grow.
Single point of failure: A host outage stops all document editing in ILIAS until the server returns, so confirm whether that is acceptable for course and staff workflows.

Before you choose this model, ask the Collabora Online vendor and your platform team to confirm the supported installation method for your operating system and whether the host can meet the concurrency you expect.

Security controls for ILIAS editing sessions

Enabling Collabora Online inside ILIAS widens the path between the learning platform and the editor, so each link needs a deliberate control. The cards below cover network restriction, transport encryption, group-based rights, patching, package verification and the access records that FERPA expects institutions to keep.

Restrict WOPI requests to Collabora addresses

Limit which addresses can reach the Collabora server's WOPI endpoints so that only your ILIAS hosts and the Collabora servers you operate can exchange document requests. The Nextcloud administration manual recommends the same kind of IP restriction for WOPI traffic, and the ILIAS equivalent should be confirmed in your firewall and reverse proxy rules. Test from outside the allowed range to confirm that unexpected hosts are refused.

Use HTTPS on both sides

Serve ILIAS and the Collabora discovery URL over the same protocol, and prefer HTTPS for both, so the editor does not load content over a weaker channel than the learning platform. Check that certificates are valid and trusted by the ILIAS server, because a mismatch often appears as a failed editor launch rather than a clear security warning. Document the certificate owner and renewal process before the pilot.

Limit editor and edit rights by group

Decide which ILIAS roles can open documents in the editor and which can change them, then map those roles to the groups that the platform already manages. Read-only access suits most learners reviewing course material, while editing rights should be limited to instructors or project groups with a clear need. Review group membership each term so that former staff or completed cohorts do not keep write access.

Keep Collabora Online patched

Collabora publishes security advisories for Collabora Online. For example, the 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. Assign an owner for watching the release notes, schedule point-release updates, and confirm that your ILIAS integration still works after each update in a test environment first.

Verify package signing keys

For RPM and DEB installations, check the package signing keys before you install or update Collabora Online. The 25.04 release notes record that signing keys were updated for these users, so the key used by your package manager must match the vendor's current key. Record the fingerprint you verified and repeat the check whenever the repository configuration changes.

Log access and disclosure events

FERPA requires institutions to keep a record of each disclosure of personally identifiable information from education records, including the parties involved and their legitimate interests, for as long as the records are kept. Confirm with your compliance lead which ILIAS and Collabora events must be captured, such as who opened or edited a student document, and where those logs are stored and retained.

Failures that stop documents opening in the editor

This table maps the failures administrators most often meet when ILIAS hands a repository document to Collabora Online, with the likely cause and a first fix for each. Read it from the symptom backward, and confirm the log locations and error text in your own ILIAS and Collabora versions before changing anything. Most of these issues trace back to discovery, protocol, trust or allow list settings, so check those four first.

Symptom	Likely cause	First fix
Editor does not open and ILIAS reports the discovery URL cannot be reached	ILIAS server cannot make an outbound request to the Collabora discovery URL, often because of DNS, firewall or proxy rules	From the ILIAS host, request the discovery URL with curl and confirm DNS resolution and firewall rules; correct the path or hostname in the WOPI settings
Documents open for some users and fail for others with mixed content or protocol errors	ILIAS is served over HTTPS while the Collabora URL or discovery address uses HTTP, or the reverse	Use the same protocol for both servers, preferably HTTPS, and update the stored Collabora URL to match
Browser shows a certificate error when the editor frame loads	The Collabora server certificate is not trusted by the browser or by the ILIAS host, or the chain is incomplete	Install a complete certificate chain on the Collabora reverse proxy and add the internal certificate authority to the ILIAS host trust store if one is used
WOPI requests are rejected by Collabora with an allow list warning	The allow list on the Collabora server does not include the ILIAS host address that sends WOPI requests	Add the ILIAS host name or address to the WOPI host allow list, then reload the Collabora configuration and retest
Users see an error or no editor button for documents they should open	The user is not in a group or role that ILIAS has permitted to use the editor	Check the group or role mapping for the editor in ILIAS, then confirm the user is a member and retest with a test account
Document opens read-only when the user expected edit rights	The repository permission grants view only, or the editor policy limits editing to certain groups	Compare the repository permission with the editor edit policy, and confirm the WOPI session requests write access for that user
Edits appear in the editor but do not persist in repository storage	The PutFile callback from Collabora to ILIAS fails, often because the ILIAS URL is unreachable from the Collabora server or the storage write is refused	Confirm Collabora can reach the ILIAS WOPI endpoints over the same protocol, then check ILIAS and web server logs for rejected PutFile requests
Sessions drop or documents fail to load after a Kubernetes replica change	The load balancer does not route by the WOPISrc parameter, so users editing one document reach different pods	Configure the ingress to route by WOPISrc, keep replica counts fixed as the Helm chart describes, and retest with two concurrent editors

Questions buyers ask before enabling Collabora Online in ILIAS

How much effort does enabling Collabora Online in ILIAS take?

The effort depends on a short list of factors: the ILIAS version you run, how many users and courses will open documents in the editor, whether Collabora runs on a dedicated server or alongside ILIAS, and how much identity and certificate work sits between the two. Each factor changes the number of configuration steps and the amount of testing. The ILIAS side is mostly enabling WOPI and entering the Collabora discovery URL, while the Collabora side involves the server, the reverse proxy, HTTPS and certificate handling. Testing with real repository documents, including permissions for editors and viewers, usually takes more time than the configuration itself. Ask any provider for a written scope that lists each of these factors and the test cases it will run before go-live.

Can our team enable Collabora Online in ILIAS without a partner?

Yes, if your team already runs ILIAS and a reverse proxy, has the skills to manage TLS certificates and DNS, and has a test instance where changes can be made safely. The work is manageable for an experienced ILIAS administrator, but the ILIAS settings for WOPI and the discovery URL should be confirmed against the release documentation for your exact ILIAS version before you change production. Plan a test course, a set of test documents and a rollback step first. A partner becomes more useful when the team lacks reverse proxy or certificate experience, needs a fixed delivery date, or wants the configuration documented and tested for auditors.

What does the institution need to provide for this integration?

Before work starts, you need to name owners for ILIAS administration, the reverse proxy and DNS, certificates, and the Collabora server, along with one decision maker who approves the access model. You also need a test course with sample repository documents in each format you expect users to edit, plus access to create DNS records and obtain or install TLS certificates for the Collabora hostname. Decide early who may open documents in the external editor and who may edit rather than only view. Those choices determine the group configuration in ILIAS and the testing plan. Confirm these items with the provider before accepting a written scope.

What does a Collabora Online license cost for ILIAS users?

The Business plan on Collabora's pricing page costs 3 euros per user per month for up to 99 users, and includes long term support, a service level agreement, signed security updates and customer portal access. For 100 or more users, the Enterprise plan is quoted with volume discounts and adds integration support, customization services and roadmap input, so you need a quote based on your user count. The license is a recurring cost, so budget it as an annual running expense. Collabora's free CODE edition is not recommended for production, so it is suitable only for testing or a pilot. Separate your costs for the license, the server and the integration work, since each is paid to a different party.

Does FERPA change how we design Collabora Online access in ILIAS?

FERPA applies to educational institutions that receive funds under a program administered by the US Secretary of Education, and it shapes the design in three ways. A contractor or hosting provider may handle education records as a school official only under the conditions in 34 CFR 99.31, including direct institutional control over use and maintenance. Institutions must use reasonable access controls so that staff open only the records they need, which means your ILIAS roles and Collabora editing groups should follow legitimate educational interest. FERPA also requires a record of each disclosure, so confirm with your compliance lead what access logs the ILIAS and Collabora servers keep and how long they are retained. Legal counsel should confirm how these rules apply to your institution.

Who should decide the editing permissions for ILIAS documents?

The course owner or repository administrator should decide who may edit, with the institution's data protection or compliance lead approving the model. Start with the principle that users open documents in the external editor only when their ILIAS role permits it, and allow editing only for named groups such as instructors or document owners. Write the rule down before configuration so that testing can check it. Revisit the rule when new course types or repository areas are added, because permission drift is a common source of unintended edits. Confirm the final access model in a test course before any production course uses it.

How DeployOpen scopes and delivers the ILIAS integration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For the ILIAS integration, we start from a written scope that fixes what is enabled, which repository objects open in the editor, and how the Collabora Online server is reached, so the work stays predictable from start to handover.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We confirm your ILIAS version, the WOPI and discovery URL settings, and which repository object types should open in Collabora Online.
We record which user roles may open documents for viewing and which may edit, and who approves that model.

How we build

We activate WOPI and the discovery URL in ILIAS and connect them to a Collabora Online server you operate.
We test that repository documents open in the external editor and that saved changes return to the correct file version.
We confirm that HTTPS, hostnames and firewall rules match the Collabora server address configured in ILIAS.

How we hand over

You receive a configuration record covering WOPI settings, discovery URL, allowed hosts and role mappings.
We document the test cases used to verify document opening, editing, saving and permission behavior.
Operating notes explain how to repeat checks after ILIAS or Collabora Online upgrades in your own environment.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
A retainer can cover re-testing after Collabora Online point releases and ILIAS version changes you plan.
Support requests are handled against the agreed scope, and any change to that scope is written down first.

Collabora Online and ILIAS integration