External OIDC seems not functional

[enticedwanderer]

Describe the bug

It doesn't seem possible to utilize external IDP currently, at least not via OAUTH2/OIDC. Migrating existing configuration from previously working owncloud setup, opencloud now tries to do a XHR GET to external IDP well known location and can't because of CORS. We shouldn't be needing CORS to begin with with a normal redirect, if opencloud was doing OIDC to spec.

Perhaps I need to customize further settings? Am I missing anything else needed to get external auth functional?

Steps to reproduce

1. Set up environment variables or config for external IDP use.
2. Set up external IDP OIDC issuer (I used Authentik)
3. Start opencloud and try to login

Expected behavior

Opencloud should redirect me to external OIDC.

Actual behavior

It fails with CORS error while opening a normal opencloud page.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://authentik.home.lan/application/o/opencloud/.well-known/openid-configuration. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.

Setup

Standard docker setup as provided in the git repo. Additional env variables for opencloud container.

Details

      # OIDC config
      PROXY_AUTOPROVISION_ACCOUNTS: "true"
      PROXY_OIDC_REWRITE_WELLKNOWN: "true"
      PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD: "none"
      OC_OIDC_ISSUER: https://authentik.home.lan/application/o/opencloud/
      WEB_OIDC_CLIENT_ID: JRf59P10id6LvrNiHDj3XGvT4DvqW2k0Kmwpjhaj
      WEB_OIDC_SCOPE: "openid profile email offline_access"

Additional context

Note that removing the configuration above and falling back to internal IDP everything seems to function as expected.

[mpldr]

I think I could narrow it down to the OIDC well-known not being included in the CSP. First tests with

	header Content-Security-Policy "default-src * 'unsafe-eval' 'unsafe-inline' data: filesystem: about: blob: ws: wss:"

	reverse_proxy http://127.0.1.2:9200 {
		header_down -Content-Security-Policy
	}

seem promising. Though, I would very much prefer to not keep this CSP.

[micbar]

In our deployment example, we include a csp.yaml file which configures the csp rules.

We have a pr to add keycloak #465

Please let us consolidate the work there.

[micbar]

Keycloak needs to be added to connect-src in the openCloud csp.yaml file.

[enticedwanderer]

I was just looking at #465 and tried to double check. I don't think the issue is with the CSP (at least in my case) since:

root@dockerino:/docker/config/opencloud# cat config/opencloud/csp.yaml  | head -n15
directives:
  child-src:
    - '''self'''
  connect-src:
    - '''self'''
    - 'blob:'
    - 'https://${COMPANION_DOMAIN|companion.opencloud.test}/'
    - 'wss://${COMPANION_DOMAIN|companion.opencloud.test}/'
    - 'https://raw.githubusercontent.com/opencloud-eu/awesome-apps/'
    - 'https://authentik.home.lan/'
    - 'https://authentik.home.lan/application/o/opencloud/.well-known/openid-configuration'
  default-src:
    - '''none'''
  font-src:
    - '''self'''

I even added the the direct URL that's failing for good measure. I think the actual issue is that Authentik is not returning in it's response Access-Control-Allow-Origin header which CORS expects to find on OC side and thus fails.

I was implying that it shouldn't have to because according to spec we should be doing a redirect to OIDC instead of a XHR request.

And yes I confirmed that csp file is being used:

root@dockerino:/docker/config/opencloud# grep -i csp docker-compose.yml
      PROXY_CSP_CONFIG_FILE_LOCATION: /etc/opencloud/csp.yaml
      # these three vars are needed to the csp config file to include the web office apps and the importer
      - ./config/opencloud/csp.yaml:/etc/opencloud/csp.yaml

[micbar]

The XHR Request you are talking about is according to spec the openID Discovery endpoint.

https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest

It is done by the web client to dynamically detect the Identity Provider and its features. All our clients do that to see where the authorize and logout endpoints are and if we have self registration enabled on the IdP.

In this case, this is problematic because it is the web client. The web client itself needs to protect itself. Web Clients nowadays are full fledged OIDC clients which have the valid access token in their control. So we need to make sure that this access token cannot be easily leaked to untrusted parties. So we protect ourselves with CORS and CSP rules.

I must admit, that this gets more and more complex. We are thinking about radical changes with the BackendForFrontend Approach.

For now, we need that extra layer of security.

[enticedwanderer]

Thanks for pointing me to that @micbar

So it looks like Authentik actually doesn't have means of controlling CORS headers outside of just setting them up yourself on the reverse proxy (see issue) According to the section just above in the OIDC spec it says CORS SHOULD be supported, but I guess that's not a strict requirement.

I have hosted at least 50+ various apps with Authentik and this is the first time I had to set up CORS which is why I was confused what's so special about opencloud. I didn't have this issue even with owncloud.

I'll try allowlisting the oc domain as an origin in my reverse proxy for authentik and see if that makes a difference.

[micbar]

I didn't have this issue even with owncloud.

CSP was introduced with ocis 7.0.0