OIDC setup with Authelia

[zkvvoob]

Hello all,

I was wondering, has anyone been able to set up Opencloud to use an OIDC provider other than Keycloak, for example Authelia?

If so, could you share the environment variables and the provider configuration, please?

Thanks a lot!

[kulmann]

Yes, I have it set up with Authelia.

Hope this helps: https://gist.github.com/kulmann/78f012cd549e61b146be1473982f6c51

Note: I have traefik running as reverse proxy, it's in the proxy network.

[patchmonkey]

@ghostklart would you mind sharing the bits of your config you needed to put in to get as far as you have with Authentik? I can't get past the spinning wheel during login. I'm not sure if it makes a difference, but my Authentik installation is on a different host entirely (not a docker container local to opencloud). I can't make heads or tails of the opencloud documentation.

[seijihariki]

@patchmonkey I have managed to make it complete almost the full authentication using Authentik. I was stuck on the spinning wheel because of my use of confidential instead of public client type.

This fixed my CORS Issues from the Authentik side, but I still had to fix the CSP headers from the OpenCloud side (I have not managed to make the csp.yaml work for some reason, so I set it on my reverse proxy).

As you can see in my first screenshot, I had also to use an RSA signed JWT, as it did not accept HS256 JWT tokens (it complained of a missing kid).

This is also required, as by default it uses "web" as CLIENT_ID. If you plan to use other clients you will probably have to set other CLIENT_ID environment variables. I set account autoprovisioning to false, as I am using it with authentik's LDAP with provisioning disabled as I only plan to use it with existing users in Authentik anyways.

I am, though, still stuck on this message:

This is most probably due to a lack of mapping definitions between my Authentik group definitions and OpenCloud roles, but I am not sure how to set that up. I am planning to try to finish setting that up this weekend, but if you figure something out it would be great!

[seijihariki]

Actually, commenting out the LDAP configuration and enabling autoprovisioning seems to have worked somehow?

I also added a proxy.yaml as a config, but have not checked if it is required or if this is actually how it should be done.

Still, I would think you would like to map your roles properly anyway, so here it is.

It at least seems to map the roles correctly:

[ghostklart]

tried what you did, but get an issue with saying:

{
    "error": "invalid_client",
    "error_description": "Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method)"
}

And the following on the web GUI

I have set the following VARs:

WEB_OIDC_CLIENT_ID
OC_OIDC_CLIENT_ID

Seems, like either the installation does not read the vars or something...

[seijihariki]

@ghostklart

tried what you did, but get an issue with saying:

{
    "error": "invalid_client",
    "error_description": "Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method)"
}

Where is this issue displayed? Have you setup your Authentik correctly? What have you set as environment variables?

These are my only manual configuration files:

# .env.opencloud
OC_URL=https://opencloud.example.com
PROXY_TLS=false
OC_INSECURE=false

PROXY_AUTOPROVISION_ACCOUNTS=true
PROXY_ROLE_ASSIGNMENT_DRIVER="oidc"
OC_OIDC_ISSUER=https://auth.example.com/application/o/opencloud/
PROXY_OIDC_REWRITE_WELLKNOWN: "true"
WEB_OIDC_CLIENT_ID=CLIENT_ID_HERE_XXXXXXXXXXXXXXXXXXXXXX
WEB_OIDC_SCOPE=openid profile email groups
PROXY_USER_OIDC_CLAIM="preferred_username"

ONLYOFFICE_DOMAIN=onlyoffice.example.com

OC_JWT_SECRET=XXXXXXXXXXXXXXXXXXXXXX # Generated Random String
OC_TRANSFER_SECRET=XXXXXXXXXXXXXXXXXXXXXX  # Generated Random String
OC_MACHINE_AUTH_API_KEY=XXXXXXXXXXXXXXXXXXXXXX  # Generated Random String

START_ADDITIONAL_SERVICES="notifications"

# docker-compose.yml
name: opencloud

services:
  opencloud:
    container_name: opencloud
    image: opencloudeu/opencloud-rolling:${OPENCLOUD_VERSION:-latest}
    restart: always
    volumes:
      - ${APPDIR}/opencloud-config:/etc/opencloud
      - /data/test:/var/lib/opencloud
    env_file:
      - .env.opencloud
    networks:
      web_access:
    entrypoint:
      - /bin/sh
    command: ["-c", "opencloud init || true; opencloud server"]

# ${APPDIR}/opencloud-config/proxy.yaml
role_assignment:
  driver: oidc
  oidc_role_mapper:
    role_claim: groups
    role_mapping:
      - role_name: admin    # Opencloud role name
        claim_value: ADMINGROUP_XXXX # Authelia group name
      - role_name: user
        claim_value: USERGROUP_XXXX

And the reverse proxy configuration. Provider configuration is as shown on my screenshot from before. Oh, another thing is that on any change to the ENV vars I had to delete the generated configuration file. If not, changes were NOT applied correctly.

So in my case, I had to delete the ${APPDIR}/opencloud-config/opencloud.yaml and it would initialize opencloud (due to my command in the docker-compose file) again after every change I made to .env. It may be that you have not deleted this file and it is using an outdated configuration.

[scetu]

I have sucesfully setup Authelia with Opencloud, here what I have done.

I have copied opencloud-full example into directory opencloud-full and this is what I am editing. I already have existing Authelia setup and running in different stack and accessible via public url (you need to make sure that Opencloud can reach Authelia's OIDC endpoints /.well.known/openid-connect and /api/oidc/token).

Authelia setup

User database (users_database.yml)

###############################################################
#                         Users Database                      #
###############################################################

# Change password with 
# authelia crypto hash generate argon2

users:
  myuser:
    disabled: false
    displayname: "My Authelia User"
    password: "$argon2id$myhashedpassword"
    email: my.user@example.com
    groups:
      - admins

OIDC provider (configuration.yml)

Key parts:

• CORS – add the token endpoint and whitelist your OpenCloud origin URL
• Clients – one client for the web UI, one loop-back client for the desktop sync app

##
## Identity Providers
##
identity_providers:
  oidc:
    lifespans:
      access_token: '1 hour'
      authorize_code: '1 minute'
      id_token: '1 hour'
      refresh_token: '90 minutes'
    cors:
      endpoints:
         - 'authorization'
         - 'token'
         - 'revocation'
         - 'introspection'
         - 'userinfo'
      allowed_origins:
        - 'https://opencloud.example.com'
      allowed_origins_from_client_redirect_uris: false

    clients:
      - client_id: opencloud-web
        client_name: OpenCloud
        public: true
        authorization_policy: two_factor
        consent_mode: auto
        pre_configured_consent_duration: 1w
        audience: []
        scopes:
          - openid
          - email
          - profile
          - groups
          - offline_access
        redirect_uris:
          - https://opencloud.example.com/
          - https://opencloud.example.com/oidc-callback.html
          - https://opencloud.example.com/oidc-silent-redirect.html
        grant_types:
          - refresh_token
          - authorization_code
        response_types:
          - code
        response_modes:
          - form_post
          - query
          - fragment
        userinfo_signed_response_alg: none

      - client_id: OpenCloudDesktop
        client_name: OpenCloud Desktop Client
        public: true
        authorization_policy: one_factor
        consent_mode: auto
        pre_configured_consent_duration: 1w
        audience: []
        scopes:
          - openid
          - groups
          - profile
          - email
          - offline_access
        redirect_uris:
          - http://127.0.0.1
        grant_types:
          - refresh_token
          - authorization_code
        response_types:
          - code
        response_modes:
          - form_post
        userinfo_signed_response_alg: none

Restart Authelia after saving the file.

Opencloud configuration

Edit opencloud-full/opencloud.yml and add these environment variables to the opencloud service:

services:
  opencloud:
    environment:
      # Authelia - OIDC
      OC_OIDC_ISSUER: https://authelia.example.com
      WEB_OIDC_CLIENT_ID: opencloud-web
      ## Proxy
      PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD: none
      PROXY_AUTOPROVISION_ACCOUNTS: "true"
      PROXY_ROLE_ASSIGNMENT_DRIVER: "oidc"
      PROXY_USER_OIDC_CLAIM: "preferred_username"
      PROXY_USER_CS3_CLAIM: "username"
      ## role assignment
      PROXY_ROLE_ASSIGNMENT_OIDC_CLAIM: 'groups'
      WEB_OIDC_SCOPE: openid profile email groups
      GRAPH_ASSIGN_DEFAULT_USER_ROLE: "true"
      GRAPH_USERNAME_MATCH: "none"
      OC_EXCLUDE_RUN_SERVICES: "idp"
      PROXY_CSP_CONFIG_FILE_LOCATION: /etc/opencloud/csp.yaml

Content-Security-Policy

Tell the browser it’s safe for the Opencloud to call Authelia URL in opencloud-full/config/opencloud/csp.yaml:

directives:
  connect-src:
    - 'https://authelia.example.com/'
  frame-src:
    - 'https://authelia.example.com/'

Role mapping

You need to have running radicale container for mapping to work.

Map Authelia groups to OpenCloud roles in opencloud_full/config/opencloud/proxy.yaml:

role_assignment:
    driver: oidc
    oidc_role_mapper:
        role_claim: groups
        role_mapping:
            - role_name: admin    # Opencloud role name
              claim_value: admins # Authelia group name

You can view default Opencloud roles in services/settings/pkg/store/defaults/defaults.go, for example admin role:

	return &settingsmsg.Bundle{
		Id:          BundleUUIDRoleAdmin,
		Name:        "admin",
		Type:        settingsmsg.Bundle_TYPE_ROLE,
		Extension:   "opencloud-roles",
		DisplayName: "Admin",
		Resource: &settingsmsg.Resource{
			Type: settingsmsg.Resource_TYPE_SYSTEM,
		},

You can find more about groups and Opencloud configuration in OpenID Connect Identity Providers docs

[zkvvoob]

@scetu

Maybe you need to pass another environment variable to your compose such as OC_EXCLUDE_RUN_SERVICES: idm

Well, I replaced idp with idm, but that didn't seem to do the trick. I also tried with both: idp, idm.

[michaelalbertshofer]

@scetu With your configuration examaple i got the Login via WebUi to work, I have a very similar setup to yours. But the Login via Desktop App (im on MacOS) doesn't work, nor the Login via iOS app.
Dis you manage to get this to work?

I get the error "ERR Error mapping role names to role ids error="no roles in user claims"

This happens only for OpenCloudDesktop and OpenCloudIOS (I added this public client also with the variables from OpenCloud Documentation)

[scetu]

@zkvvoob my best bet is to start from scratch with opencloud_full folder, and enable (setup) only services what you need.

Also I have just realized you are missing radicale in your compose:
https://github.com/opencloud-eu/opencloud/blob/main/deployments/examples/opencloud_full/radicale.yml

Without this, my mappings were not working. Radicale is using the proxy.yaml

[scetu]

@michaelalbertshofer I have just downloaded Linux Desktop client and it also does not work. Seems like the client issue, see opencloud-eu/desktop#217 (comment)

[scetu]

I have updated the guide with fixes to consent_mode, which is now auto, directives in csp.yml now includes frame-src: for Authelia domain.
Without these fixes, Opencloud WebUI is unable to obtain refreshed token from Authelia and Opencloud will logout user after specified lifespans.

[patchmonkey]

I've also tried every suggestion above to no avail deployments/examples/opencloud_full scheme, but no matter what I tweak or how I tweak it, I can't seem to get past the CORS issue (My authentik provider is set to public and has an RSA key, i've tried adding a number of CORS related labels to the various containers based on advice elsewhere, etc.) The opencloud full example is also a bit all over the place and hard to parse without explanation. I'm not trying to be overly critical, I know there's a lot of work to be done on this project still, and I've seen it said that the issues with OIDC integration to other external IdPs is a lack of documentation, but I don't think that's accurate...given the amount of issues people in this thread have had getting to work, it seems like it does work, but the overall experience is undocumented and really tempermental.

I'll probably tear down my installation, try to pare down the docker files, and give it another shot, but it seems like some work may need to be done to make the whole process of oidc integration more straightforward

[micbar]

I have the feeling we are mixing up different IdPs and issues here.

1. That Discussion started in the context of Authelia, IMHO Authentik should not be discussed here.
2. CORS and Routing issues are independent of OIDC

@patchmonkey

We added large amounts of docs about general OIDC here https://docs.opencloud.eu/docs/admin/configuration/authentication-and-user-management/

There is also a deep explanation about Keycloak and OpenCloud.
There is a reason, why we are supporting that scenario: It is proven and can be used in Enterprise Scenarios.

The general issue is, that every OIDC provides is doing things "a little bit different". So it is hard to maintain docs about all the "specialties" and different approaches.

From my POV, it would be a quick win to put all the learnings in this thread together for a "OpenCloud & Authelia" documentation.

[patchmonkey]

Thanks, @micbar. I think that's fair given the OP's question was about Authelia, but (selfishly as an Authentik user) I would point out that there are several people in this thread who are using/mentioned Authenik, and I don't think That should be eschewed just because the main discussion started with Authelia. Maybe a secondary document for Authentik integration can be added? I'd be willing to help contribute.

Additionally, I think it's fair to say every IdP does OIDC slightly differently, that's certainly the case...as someone whose used several (keycloak, zitadel, authentik), I've noticed that as well, however, I would argue that the primary differences between IdPs are terminology and how thinks are accomplished/configured in the IdP. To clarify the point I was trying to make is that both the required Environment variables and the current documentation about OIDC integration is inconsistent or not posted. Here's a few examples of what I mean:

1. The variables required to be set to get OIDC working with an external IdP are not consistent; some start with "OC_", some start with "PROXY_", some start with "WEB_". I realize renaming these is not always the easiest thing to do, but having a consistent prefix for variables required for OIDC connectivity would be ideal. There are also some keycloak specific variables, which makes its seem like other OIDC providers may eschewed, but admittedly that may be just me reading into it a bit too much.
2. The docs you mentioned about OIDC focus primarily on Keycloak and clients, and they don't really mention generic OIDC, and they're unclear about the requirements/how-to's. For example:
   • The doc doesn't to mention whether or not the OIDC client should be private or public
   • The doc doesn't to mention it expects the encryption certificate to be RSA (which has been mentioned by some users above)
   • The doc doesn't mention the variable for "Client ID", which is a main component for many OIDC integrations
   • The doc mentions LDAP is recommended via keycloak, but is LDAP required for OIDC in general? Is it required in Keycloak?

I don't mean any of this to come off as overly critical, The project in general looks amazing and I'm excited for where it's headed, I just think/hope there are still some backlog tasks to further improve documentation and configuration interface for non-keycloak OIDC.

[micbar]

The variables required to be set to get OIDC working with an external IdP are not consistent; some start with "OC_", some start with "PROXY_", some start with "WEB_". I realize renaming these is not always the easiest thing to do, but having a consistent prefix for variables required for OIDC connectivity would be ideal. There are also some keycloak specific variables, which makes its seem like other OIDC providers may eschewed, but admittedly that may be just me reading into it a bit too much.

In OpenCloud we always prefix the env variables with the name of the service. That has been a design decision and is not so easy to change.

The docs you mentioned about OIDC focus primarily on Keycloak and clients, and they don't really mention generic OIDC, and they're unclear about the requirements/how-to's. For example:

The doc doesn't to mention whether or not the OIDC client should be private or public

https://docs.opencloud.eu/docs/admin/configuration/authentication-and-user-management/external-idp#client-configuration explains that all clients need to be public clients.

The doc doesn't to mention it expects the encryption certificate to be RSA (which has been mentioned by some users above)

I didn't get that comment. OpenCloud uses https via TLS. Where does RSA come into place?

The doc doesn't mention the variable for "Client ID", which is a main component for many OIDC integrations

The client ID is set on the IdP. https://docs.opencloud.eu/docs/admin/configuration/authentication-and-user-management/external-idp#client-configuration lists all openCloud client IDs. They are fixed in the OpenCloud clients. There is nothing to configure on the OpenCloud side

The doc mentions LDAP is recommended via keycloak, but is LDAP required for OIDC in general? Is it required in Keycloak?

OpenCloud has no database, therefore it stores the users in LDAP. There are two scenarios, one with an external and one with an Internal LDAP server. ("Shared Directory mode" and "Autoprovisioning mode"). Both scenarios are explained step by step with diagrams and all needed Configuration and a pointer to a real world example in docker compose. What is missing? We are always happy to improve.

[patchmonkey]

First of all, thank you. Your above explanation cleared up a LOT for me. I appreciate you taking the time.

In OpenCloud we always prefix the env variables with the name of the service. That has been a design decision and is not so easy to change.

Unfortunate from an end user perspective imo, but understandable. Is there a full list of available variables somewhere with explanations of what each does? I wasn't able to find one. That would be extremely helpful.

https://docs.opencloud.eu/docs/admin/configuration/authentication-and-user-management/external-idp#client-configuration explains that all clients need to be public clients.

The first few times I read this section I completely missed that it mentions these need to be public. To be honest, I completely misunderstood what this section was for. I at first took "Client Configuration" to mean configuration settings on the desktop and mobile applications, and it wasn't until I re-read the single sentence under this header that I realized my misunderstanding.

I didn't get that comment. OpenCloud uses https via TLS. Where does RSA come into place?

This was something mentioned by @seijihariki above in one of his posts. I didn't run into this personally so I can't ellaborate. I think it has to do with the encryption algorithm used within Authentik, but I'm not certain.

The client ID is set on the IdP. https://docs.opencloud.eu/docs/admin/configuration/authentication-and-user-management/external-idp#client-configuration lists all openCloud client IDs. They are fixed in the OpenCloud clients. There is nothing to configure on the OpenCloud side

I did not understand that the administrator must change the Client ID to match what is listed in this document, and these Client IDs are hardcoded in OpenCloud and not reconfigurable from reading this document. I think the document should be a bit more explicit about that, as the user experience here diverges from many common OIDC/IdP integrations. I've integrated over 20 separate applications with my IdP, This is the first I've personally come across where this would seem to be the case. When creating new clients within the IdP, the IdP generates a unique Client ID which usually gets configured on the application side.

OpenCloud has no database, therefore it stores the users in LDAP. There are two scenarios, one with an external and one with an Internal LDAP server. ("Shared Directory mode" and "Autoprovisioning mode"). Both scenarios are explained step by step with diagrams and all needed Configuration and a pointer to a real world example in docker compose. What is missing? We are always happy to improve.

Thanks, this helps explain the role of LDAP a little better, and why it's required. There are a couple of pieces about this quote I want to comment on. Your explanation makes sense While the lack of databases is definitely mentioned, it was not immediately apparent to me that LDAP would be required for this because of the design decision not to use databases. I think it would be really helpful to mention what you've said here explicitly in the documentation, because it helps prospective users understand the basic requirements (and why they're required). Part of the confusion around the document explaining Shared Directory vs Autoprovisioning is that the doc specifies that's for Keycloak, and as someone who is not using keycloak and doesn't have all of the required information to make a non-keycloak IdP work, I was sure how much of the "Keycloak" specific documents and sections I needed to delve into and distill out to use in my setup.

Additionally, the documents have a wealth of information, but there are parts of them are sparse, and they are not optimized to help an administrator walk through process of enabling OIDC Sequentially: (e.g. First set these variables, then create a provider in your IdP, then create several clients in your IdP, then restart your containers, etc.)

What is missing? We are always happy to improve.

tl;dr

• A list of all possible ENV variables with explanation for what they do in a single place
• Documents that reflect required information/steps for all/generic OIDC/IdPs, with IdP-specific implementation steps/consideration/requirements in a separate document
• Documents that provide a specific sequential set of operations to enable external OIDC (more like the document found here

Thanks again for your explanation and patience.

[seijihariki]

I didn't get that comment. OpenCloud uses https via TLS. Where does RSA come into place?

This was something mentioned by @seijihariki above in one of his posts. I didn't run into this personally so I can't ellaborate. I think it has to do with the encryption algorithm used within Authentik, but I'm not certain.

It is more about the specific signing algorithm used for signing the JWT tokens. I was not able to make it work while using HS256, but it worked with no problems when using an RSA key (RS256 as the signing algorithm). I guess it makes sense, considering HS256 is a symmetrical algorithm, but I noted it above because I was having problems with a missing kid in the crypto header in the JWT before the change to RS256.

[seijihariki]

@patchmonkey

Here are my final configurations on Authentik:

If your problems are with CSP, here are my configurations as I set them in my nginx:

# strip any upstream CSP
proxy_hide_header Content-Security-Policy;

# now inject your full, single-line policy
add_header Content-Security-Policy
  "default-src 'none'; child-src 'self'; connect-src 'self' blob: https://opencloud.example.com https://auth.example.com wss://opencloud.example.com https://raw.githubusercontent.com/opencloud-eu/awesome-apps/; font-src 'self'; frame-ancestors 'self'; frame-src 'self' blob: https://embed.diagrams.net https://onlyoffice.example.com https://collabora.example.com https://docs.opencloud.eu; img-src 'self' data: blob: https://raw.githubusercontent.com/opencloud-eu/awesome-apps/ https://onlyoffice.example.com https://collabora.example.com; manifest-src 'self'; media-src 'self'; object-src 'self' blob:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"
  always;

auth.example.com being the host of my Authentik instance.

[StafLoker]

@seijihariki Can u make resume of configuration (Authentik configs, .env of opencloud (OpenID), etc.). Because I try to configurated like OwnCloud (https://helgeklein.com/blog/owncloud-infinite-scale-with-openid-connect-authentication-for-home-networks/), I had infinit loading in login.

[Karstensson]

Did anyone manage to sort out logout with authelia?

[micbar]

Last time as i checked, there was no logout implemented in authelia.

[Karstensson]

There is a logout button in the Authelia web interface, but you can also send a redirect to https://authelia.domain.com/logout which I use for other services to log out. The issue here is that I cannot find a working way to get opencloud to redirect to that page.

[micbar]

I think there is an option in web.

@kulmann can you help?

[Karstensson]

Just a note: I have tried WEB_OIDC_POST_LOGOUT_REDIRECT_URI: 'https://authelia.domain.se/logout' but does not seem to work.