Collabora Online SSO and identity integration

Once single sign-on is working, the risk moves from setup to drift. Identity settings change, certificates and client secrets expire, group memberships grow, and Collabora Online receives point releases. Plan these tasks as recurring operations with named owners before cutover, because the failures they prevent usually appear weeks later as a sudden wave of users who cannot open documents. Start with the signals. On the WOPI host side, watch failed sign-in attempts at the identity provider and token rejections in the host's logs, since these show whether users are failing at authentication or at the handoff to Collabora. On the Collabora side, watch coolwsd logs for WOPI access errors, particularly responses to CheckFileInfo and file retrieval calls that fail after a host configuration change. Confirm with your host's documentation which log entries and fields it writes for WOPI requests, and set alerts on error rates rather than single events so that one expired token does not page the on-call team. Credentials need a rotation calendar. For SAML, track the expiry of the signing certificate that the identity provider uses to sign assertions and the metadata the host trusts. For OpenID Connect, track the client secret and any signing keys the host fetches from the provider's discovery document. Confirm whether your identity provider can publish a new certificate or key before the old one expires, and test that the host accepts both during the overlap. Record who owns each credential and where it is stored, and rehearse a rotation in a staging environment at least once.

Group membership reviews are where the access model either stays correct or quietly widens. The groups that decide who may open the editor and who may edit rather than only view, such as the controls administrators can set in Nextcloud Office, should be reviewed on a schedule agreed with the data owners. Ask the identity team to export group membership, compare it with the last review, and remove accounts for leavers and role changes. Confirm whether removals in the identity provider take effect immediately for active editing sessions or only at the next token issue, and document the answer. Back up the configuration that makes sign-in work, not only the documents. That means the host's identity and Collabora connection settings, the Collabora server URL and WOPI allow list, the SAML metadata or OpenID Connect client registration, the group mapping rules, and any reverse proxy configuration that forwards authentication headers. Store these in version control or a backup system with restore tests. A restore should be proven on a separate instance, and the restore runbook should state which secrets must be re-issued rather than copied. For updates, follow the Collabora point release and signed package process for your deployment method, and confirm the package signing keys your RPM or DEB repositories trust. Security advisories are published by Collabora, so subscribe to them and record the date each fix was applied. Test each update against your SSO flow, because a change in the server can alter how tokens or WOPISrc parameters are handled.

The documentation package is what auditors and your own successors will read, so it should be produced as part of the handover. DeployOpen can prepare the operational runbooks, the group-to-right mapping showing which identity groups grant view or edit access, configuration records, backup and restore test results, and change logs that map identity changes to approvals. Ask for the exact list and format in the written scope so that it is agreed before work starts. Compliance evidence is prepared by DeployOpen, but audit reports and attestations come from independent auditors and certification bodies, and DeployOpen does not issue them. Agree with your auditor which records they need, how far back they will sample, and who holds the source systems that produce the evidence. The handover should name the owner of each recurring task, the escalation path to the identity team and the Collabora support channel you have, and the calendar for certificate renewal, group reviews and point release testing. Confirm with your identity provider and Collabora which support terms apply to your subscription edition before you rely on them in the runbook.

The goal of testing Collabora Online single sign-on is to confirm that a failed or unclear identity check leaves the user without access or with view-only access, never with edit rights they were not granted. Collabora Online does not run its own user directory for this flow. The WOPI host, such as Nextcloud, authenticates the person through its SAML or OpenID Connect configuration, then issues a WOPI access token that Collabora Online accepts for a single file. Each test below should therefore be run against the host and the editor together, because a pass on one side can hide a failure on the other.

Start with three sign-in cases: a user in the view group, a user in the edit group, and a user in neither group. In Nextcloud Office, administrators can limit which groups may use the editor and which may edit rather than only view, according to the Nextcloud administration manual. For each account, open a document from the host, then record the rights shown in the editor toolbar and whether the file can be saved. The no-access user should be stopped before the editor loads. Use a test account in each group and repeat the sign-in after any group change, since cached sessions can keep old rights for a while. Confirm the group lookup behavior with your identity provider's documentation and your host version, because claim mapping differs between SAML and OpenID Connect setups.

Next, test removal. Disable a test user in the identity provider, or remove them from the edit group, while they have a document open in the editor. Access should end when the host session ends and any active WOPI token expires or is revoked, which you should confirm with your host and Collabora versions rather than assume. Then check that a fresh open attempt is refused. Also test a request from an address outside the WOPI allow list, which the Nextcloud manual recommends restricting to the Collabora server addresses. The request should be refused and not fall back to a looser path. Use a host outside the list to make the call and confirm the refusal appears in the Collabora log.

Mismatched configuration is the most common source of confusing failures. The Nextcloud manual recommends that the Collabora server URL use the same protocol as the Nextcloud installation, preferably HTTPS. Deliberately set a mismatched protocol or host name in a staging environment and confirm that the editor fails visibly with an error rather than opening in a degraded state. Also test expired or rotated credentials: rotate the WOPI shared secret or certificate in staging, then open a document and confirm that the token check fails. Note whether the error is shown to the user and whether it names the cause, since an opaque error will slow down support teams in production.

For each test, record the expected result before running it and check logs on both sides. On the host, review the authentication and sharing logs for the sign-in attempt, the group decision and the token issue. On the Collabora side, review the coolwsd logs for the WOPI request, the source address, the file identifier and the refusal reason. Matching timestamps across the two systems make failures far easier to trace. Keep the results in a short test record that names the versions tested, because a fix in a later point release may change the behavior. Ask your implementation partner to include these cases in the acceptance tests, and confirm with Collabora which log levels and fields your release provides.