WIP: OIDC with Authelia

[Josue-T]

The problem

YunoHost/issues#676

Solution

Replace the current SSO (ssowat by Authelia with provide natively OIDC)

PR Status

Work in progress

Related PR: YunoHost/yunohost-portal#34

How to test

• Checkout the branch
• Install Authelia

TODO

• (WIP) Fix portal API to work with Authelia
• add new authelia configuration
• handle the debian packaging of authelia as dependency
• rework nginx config
• migrate permission handling from ssowat to Authelia
• cleanup all dependency to ssowat and replace it with Authelia
• rework the way we handle the portal domain. With authelia the portal domain for example.com could be by example -auth.example. com, so we need to add a way to be able to define the portal domain for each main domains.
• provide a compatibility layer for nginx config of apps (ideally we need to provide it for packaging v1,v2) and we can maybe introduced a new recommended configuration for packaging v3 with breaking change ? cf WIP: Packaging v3 #2070
• provide a new resources for apps for OIDC configuration
• probably we need to write a migration for some stuff... ?

[Josue-T]

@zamentur, @alexAubin, any idea how to handle this case ? The issue now with Authelia is that we don't have the password so we can't just authenticate to LDAP with the user credentials. I thought about theses possibilities:

• Request the user to provide the password (in a popup), this can also be considered as a security to "reauthenticate" the user to change the user settings.
• Do some tweak with the LDAP authentication (by example with unix socket maybe) to give the possibility to portal-api to send edit request to LDAP without needing to do a authentication with user/password.
• Or we can also decide to create a dedicated system user for the SSO operation. Event if we can allow Anonymous request with Authelia, they really recommend to use Authentification. There are this issue about this: Support anonymous lookup in LDAP authelia/authelia#101. In case we would like at some point to implement password reset we will need the authentication, so to me it's also an option that we need to think about.

[alexAubin]

Naively I would say that people should re-provide the password ...

Otherwise we need to make the user running the ynh-portal api able to modify any LDAP account attribute (or maybe we could restrict to "everything but the password") but that feels very meh