Création d’une plateforme de SSO hautement disponible - Partie 1
Ayant de nombreuses applications hébergées à de nombreux endroits (différentes plateformes, différents domaines, internes/externes, etc), j’ai besoin d’une plateforme d’authentification web unique (SSO, Single Sign-On) pour contrôler l’accès à celles-ci.
J’ai testé trois plateformes open-source : Authelia, Authentik et Keycloak. Dans cette premièrre partie, nous parlerons du choix de la solution, le déploiement sera traité dans une seconde partie.
Choix de l’application
Critères
Cette plateforme d’authentification doit répondre à plusieurs critères qui conditionneront le choix du logiciel qui répondra au besoin, et à la méthode de déploiement choisie.
Mes critères sont les suivants :
- Support des authentifications simples par proxy/ingress.
Nombreuses sont les applications qui ne supportent pas du tout d’authentification externe (voire pas d’authentification du tout), le proxy/ingress se chargera donc d’authentifier l’accès aux applications en interrogeant la plateforme SSO par une simple requête HTTP. La documentation de Nginx en résume le fonctionnement. - Authentification d’applications hébergées sur des noms de domaines multiples.
Beaucoup de ces applications tournent sur des noms de domaines différents, certains internes, d’autres publics. La plateforme doit être unique et authentifier toutes ces applications. - Support de LDAP en source d’identités.
Ma source d’identités est Microsoft Active Directory, qui expose du LDAP(S). La plateforme doit donc sourcer les identités (utilisateurs et groupes) via LDAP. - La plateforme doit être hautement disponible (HA, High Availability).
Cette plateforme va authentifier de nombreuses applications, notamment celles qui contrôlent mes cluster Kubernetes, mes hyperviseurs. Elle doit donc avoir le moins de downtime possible, et ne doit pas dépendre de ce qu’elle authentifie. - Authorisation (binaire) basée sur les groupes
La plateforme de SSO doit autoriser (ou pas) l’accès à l’application entière en fonction des groupes de l’utilisateur. La granularités dans les droits n’est pas un critère, donc la réponse doit être simplement accès autorisé, ou refusé.
Applications envisagées
Authelia
Authelia est une solution populaire parmis les “Homelabbers” pour répondre à ce besoin.
Elle est conçue pour authentifier par proxy des petits logiciels web de façon simple.
Je l’ai longtemps utilisée au sein de mon cluster Kubernetes en raison de sa simplicité de déploiement.
Elle a l’avantage de proposer des authorisations et politiques d’authentifications en fonction de regex d’URL. Cela limite le nombre de politiques différentes à créer, en contrôlant par exemple l’accès en fonction du sous-domaine, ou du domaine parent.
En revanche, elle ne sait authentifier que des applications qui résident sur le même parent qu’elle. Par exemple, si elle est installée sur un domaine auth.mondomaine1.com, elle ne saura authentifier que des applications déployées sur mondomaine1.com (ainsi que ses sous-domaines), pas mondomaine2.fr. C’est principalement cette raison qui m’a fait changer de solution. Cette fonctionnalité est toutefois sur sa roadmap.
👍 Avantages
- Simple et rapide à déployer.
- Support de politiques d’authorisation basées sur des regexp d’URL.
👎 Inconvénients
- Documentation bien faite mais spartiate.
- Pas de support d’applications sur plusieurs domaines, ce qui signifie qu’elle doit être déployée plusieurs fois (une fois par domaine). Cela signifie aussi que l’authentification doit être refaite sur chaque instance de Authelia, et que ses données ne sont pas partagées, ce qui importe notamment pour l’authentification multi-facteurs ou passwordless.
KeyCloak
KeyCloak est une application bien connue du monde de l’entreprise en raison de sa puissance, et de sa gestion par RedHat.
Elle est open-source et gratuite, oritentée entreprises, et offre donc des politiques complexe d’authentification et d’authorisation.
La plupart des applications d’entreprises supportant la délégation d’authentification, KeyCloak ne propose pas d’authentification simple par proxy, mais offre uniquement de l’OIDC (OpenID Connect). Pour cette raison, je ne peux pas l’utiliser pour la plupart de mes applications, qui ne supportent pas OIDC (ou autre authentification déléguée). De plus, sa complexité d’administration rend beaucoup de tâches fastidieuses, par exemple la configuration d’authentification sans mot de passe avec WebAuthN en parallèle d’une authentification traditionnelle par mot de passe.
👍 Avantages
- Puissance et flexibilité. Elle permet de créer des politiques très granulaires.
- Robustesse. Orientée entreprises, elle est prévue pour de la haute disponibilité et l’application bénéficie de nombreuses mises à jours, audits de sécurité et patchs.
👎 Inconvénients
- Complexité. La moindre configuration est très laborieuse.
- Pas de support d’authentification simple par proxy. Elle requiert un support de la délégation de l’authentification par les applications.
Authentik
Authentik est le dernier challenger de cette sélection, et l’outil retenu.
Elle est assez jeune et moins fournie que KeyCloak, mais répond majoritairement à mon besoin : elle sait authentifier par proxy, OIDC, et d’autres méthodes (par exemple en exposant du LDAP à son tour), ce qui la rend très flexible. Elle sait également authentifier des applications hébergées sur des domaines différents.
Sa configuration est relativement simple, bien que la documentation soit là encore un peu limitée par endroits. Elle ne propose malheureusement pas de politique groupée pour plusieurs applications, il faut pour chaque domaine/sous-domaine d’application créer une nouvelle politique, une application associée, et enfin y configurer les droits, ce qui est un peu fastidieux.
Son support de FIDO WebAuthN (commercialement appelé “Passkeys”) est présent et fonctionne correctement, ce qui signifique que je peux m’identifier simplement, sans mot de passe, en passant soit par Google Chrome et la Keychain iCloud (avec validation par TouchID ou Apple Watch), ou bien avec Bitwarden, mon gestionnaire de mots de passe.
Authentik commence à proposer des fonctionnalités RBAC (Role-Based Access Control), pour créer des politiques plus granulaires d’authorisation. Dans mon cas, je ne les utilise pas.
👍 Avantages
- Flexibilité et compatibilité. Authentik propose de nombreuses façons de s’authentifier.
- Compatibilité multi-domaines.
- Configuration relativement simple.
👎 Inconvénients
- Ajout d’applications assez fastidieux. J’aurais souhaité voir des politiques similaires à ce qu’Authelia propose (regex par URL).
- Documentation assez claire mais un peu limitée.
La plateforme retenue étant Authentik, nous verrons dans un second post comment la déployer pour assurer une disponibilité la plus haute possible.