Skip to content

OCM: owner/sender sent to remote providers contain the OIDC issuer URL when an external IdP is used (breaks Nextcloud receivers) #3783

Open

Description

@chodid

Describe the bug

With an external OIDC provider (Keycloak, OC_OIDC_ISSUER=https://idp.example.org/realms/example, OC_EXCLUDE_RUN_SERVICES=idp), outgoing OCM shares carry owner and sender with the issuer URL inside the identifier:

<uuid>@https://idp.example.org/realms/example@cloud.example.org

LocalUserFederatedID (pkg/ocm/user) appends the user's IdP to the opaque id whenever it differs from the provider domain. With an external IdP the IdP is the issuer URL (it is also persisted per node as user.oc.owner.idp). Nextcloud splits a cloud id at the last @ before the first : or /, i.e. at the first @ here, and derives the remote server https://idp.example.org/realms/example@cloud.example.org/. Discovery fails and the share is unusable.

The OCM address format is <identifier>@<fqdn> without scheme. This looks related to #3262 and opencloud-eu/reva#774 / #3563 (normalising accepted-user ids on the invite handshake), but this report is about the owner and sender of outgoing shares (CreateOCMShare).

Steps to reproduce

  1. OpenCloud 7.2.4 with an external IdP as above, OC_ENABLE_OCM=true, ocmproviders.json trusting a Nextcloud 35.0.2 (Contacts app 8.9.2, OCM invites enabled).
  2. POST /sciencemesh/generate-invite, accept the invitation on the Nextcloud side – works.
  3. Share a folder with the federated user via POST /graph/v1beta1/drives/{drive}/items/{item}/invite (role "Can edit") – returns 200.
  4. On Nextcloud, list the pending remote share.

Expected behavior

Owner and sender are sent as <uuid>@cloud.example.org (no scheme, no issuer path), independent of the IdP in use.

Actual behavior

Pending share on Nextcloud:

{
  "remote": "https://idp.example.org/realms/example@cloud.example.org/",
  "owner": "<uuid>@https://idp.example.org/realms/example@cloud.example.org"
}

Nextcloud log: error while discovering ocm provider (cURL: could not resolve host idp.example.org/realms/...), later Failed to test remote URL.

Setup

Docker opencloudeu/opencloud:7.2.4, relevant variables:

OC_URL: "https://cloud.example.org"
OC_OIDC_ISSUER: "https://idp.example.org/realms/example"
OC_EXCLUDE_RUN_SERVICES: "idp"
PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD: "jwt"
PROXY_USER_OIDC_CLAIM: "preferred_username"
PROXY_USER_CS3_CLAIM: "username"
STORAGE_USERS_DRIVER: "posix"
OC_ENABLE_OCM: "true"
OCM_OCM_PROVIDER_AUTHORIZER_PROVIDERS_FILE: "/etc/opencloud/ocmproviders.json"

Additional context

  • Setting USERS_IDP_URL, GROUPS_IDP_URL and AUTH_BASIC_IDP_URL to the bare domain does not help for existing data, because the issuer is stored on every node.
  • Test only: after rewriting user.oc.owner.idp of the shared folder and the space root to cloud.example.org, Nextcloud received <uuid>@cloud.example.org and discovery worked. So the identifier format is the only cause of this step.
  • Suggestion: when building federated ids, use only the host of the IdP or always send <opaque>@<provider_domain>, and map back on incoming requests.
  • Nextcloud has further problems with OpenCloud shares (ownCloud detection via status.php, Basic auth instead of the OCM uri): [Bug]: OCM shares from OpenCloud (reva) are unusable – detected as ownCloud via status.php (shareinfo 401 → share removed) and OCM webdav uri ignored nextcloud/server#65770
  • Drafted with AI assistance (Claude), reviewed by me.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions