So this works for the WEB authentication, however it seems that the desktop client (and therefor I assume the mobile apps too) do not request groups, or any other scope. They are hardcoded for openid offline_access email profile only (lacking groups or any other scope to use for a role provider).
I found a git issue for this: owncloud/ocis/issues/6814
The provided example for Keycloak includes providing scopes that Authelia does not support (Authelia only supports openid, groups, profile, email).
With my limited understanding I am unsure how oCIS gets the roles from Keycloak since it is not requested by the clients, and AFAICT I have setup Authelia to provide the roles (via groups).
I do not understand how roles is assigned or provided, and to be quite frank, I don’t understand the entire example.
But my take away from it seems to be that it leaves me with the following options of:
build your own clients (not viable, I’m not in a position to build apps)
not use mobile/desktop clients (not ideal)
just cant use PROXY_ROLE_ASSIGNMENT_DRIVER: oidc (also not ideal)
Am I just doing something wrong or is it not feasible at the moment?
I’ve tried everything to make this work, unfortunately it doesn’t.
The only solution to create an admin and have all 3 clients working (web, desktop, android) was to install ocis without authelia, create the admin user and password same as your authelia user, then add authelia.
After you login with the admin, one can add PROXY_AUTOPROVISION_ACCOUNTS: "true" and future clients can be added in authelia and will be provisioned in ocis (as normal users naturally).
After pulling the latest oCIS (owncloud/ocis@sha256:bb78d72b006dcbceee216decf3a09eed52f451e1591b5866c0ff614469a69f2b), I found that it could no longer communicate with Authelia. The debugging console disclosed the culprit:
Refused to connect to 'https://authelia-host/.well-known/openid-configuration' because it violates the following Content Security Policy directive: "connect-src 'self'".
This was easy enough to fix at the reverse proxy by removing or rewriting the offending CSP header. Using Caddy v2, one of the following lines would do the job (last option is most precise):
header -Content-Security-Policy # nuke the entire CSP header
header >Content-Security-Policy "connect-src 'self'" "connect-src *" # allow XHR anywhere; preserve other directives
header >Content-Security-Policy "connect-src 'self'" "connect-src 'self' authelia-host" # allow XHR to self and IdP; preserve other directives
… but it bears asking: how would one configure oCIS to customize the CSP header? I see there’s a PROXY_CSP_CONFIG_FILE_LOCATION variable that supposedly specifies a “CSP configuration file,” but what would one write into this CSP configuration file? And, would it be possible to configure this using environment variables alone, without additional files?
Unfortunately this is not possible at the moment. It would require a lot of new envvars which makes it unmaintainable. That is why we did go for having an external file configuring csp in a clear and concise way.