SAML on Zwindler's Reflection

S'authentifier sur Proxmox VE avec Keycloak

Wed, 11 May 2022 12:30:00 +0000

Résumé des épisodes précédents

Cet article est la suite d’un article que j’avais sorti en aout dernier (time flies…) sur l’installation de Keycloak (sans utiliser l’image Docker).

J’avais bien entendu une idée derrière la tête (on installe pas un Keycloak pour le plaisir ?). cette idée était de tirer parti de l’authentification OIDC qui venait d’être ajoutée à Proxmox VE 7.

Je pars donc du principe que vous avez un serveur Keycloak fonctionnel et on va s’en servir pour ajouter l’authentification OIDC à notre cluster PVE.

Getting Started

Dans l’article précédent, je vous avais laissé au moment où on se connectait à l’UI de Keycloak, et qu’on arrivait sur le “Getting Started”. Si vous voulez plus de détails sur cette étape, je vous conseille de lire l’article de documentation associé sur le site officiel.

Nous, on va commencer direct par la création d’un “Realm”.

Dans un contexte multi client ou multi entreprise, les Realms vous permettraient d’avoir un Realm par client par exemple, chacun avec son propre système d’authentification (LDAP, AD, …).

Ici, on ne va pas d’embêter, je fais un realm pour mon Proxmox et il servira juste pour ça.

Créer un Realm

C’est peut-être un manque d’habitude, mais j’ai pas trouvé la navigation entre “Realm” hyper intuitive, au début. En fait, par défaut vous êtes sur un realm “master” (visible tout en haut à gauche de l’écran, sous le logo Keycloak).

En cliquant sur la flèche qui va vers le bas, à droite de “Master”, on ouvre un menu déroulant, qui dévoile option “Add realm”.

On lui donne un petit nom et c’est bon.

Créer un client

Dans la terminologie Keycloak (OIDC en général), un client, ça va en fait être notre application qui va déléguer l’authentification à Keycloak.

Dans le realm Proxmox, on va donc créer un client pour ProxmoxVE.

On lui donne un petit nom, mais surtout l’URL de connexion qui va avec (on prend le premier serveur du cluster, car chaque serveur à sa propre URL de connexion à l’UI, mais on va gérer ça plus tard).

Vous devriez ensuite être redirigé vers les paramètres (plus complets) du client. De mémoire, il n’y a rien à changer, les paramètres par défaut sont bons, sauf si vous avez plusieurs URIs de connection.

C’est mon cas, j’ai plusieurs serveurs proxmox VE en cluster, mais je n’ai pas de loadbalancer qui me redirige sur les backends :8006 sur même URL en frontal.

Je dois donc renseigner dans la case “Valid Redirect URIs” autant d’URI que j’ai de serveurs PVE.

Créer un utilisateur dans Keycloak

Avant d’aller configurer Proxmox VE, on va vouloir ajouter des utilisateurs dans Keycloak.

Idéalement, vous avez déjà une base de comptes interne (LDAP, AD, etc) ou externe (Google Gmail, Azure AD, que sais-je encore). C’est cet “Identity Provider” que vous allez devoir connecter à votre Keycloak. Cependant, ça sort du scope de cet article.

Pour info, j’ai réussi en très peu de temps, et en suivant cet article How to setup Sign in with Google using Keycloak (lien mort, j’ai utilisé Internet Archive), à connecter mon compte gmail perso à Keycloak et je peux l’utiliser pour me logger dans ma console Proxmox.

Pour rester simple, on va seulement créer un login dans Keycloak, car l’outil offre une base de comptes interne qui suffiront pour cet article.

Dans le menu de gauche, sur le realm Proxmox qu’on vient de créer, allez dans “Manage / Users”, puis cliquez sur “Add User”.

On va vous demander des informations :

Une fois validé, affectez-lui un mot de passe.

Normalement, une fois que c’est fait, on en a fini avec Keycloak.

Configurer Proxmox VE

On peut donc aller configurer Proxmox VE. L’opération est relativement simple. Une fois loggé dans l’interface de management, on peut trouver le menu “Authentification” (dans le scope Datacenter).

On crée un provider de type OIDC :

Note: l’URL que vous devrez mettre dans issuer URL est de la forme https://mykeycloak.myexample.org/auth/realms/myrealm

Une fois que c’est fait, vous pouvez vous délogger. Dans le menu des “Realm” (les Realm au sens “Proxmox VE”, cette fois-ci) doit apparaitre maintenant “keycloak”.

Une fois que vous le sélectionnez, ça doit donner ça :

Si vous cliquez sur Login, vous serez redirigé sur une mire de login de Keycloak qui devrait ressembler à ça :

(Ou ça, si vous avez suivi le tuto pour gmail)

Enjoy !!

Bonus : debug OIDC

En partant du principe que votre Keycloak est accessible à l’URL mykeycloak.myexample.org et que vous avez créé le realm myrealm, dans lequel existe un user proxmox avec pour mot de passe KEYCLOAKPASSWORD :

curl https://mykeycloak.myexample.org/auth/realms/myrealm/protocol/openid-connect/token --user proxmox:cacf30e8-d71d-4cba-8dd6-cd1bf3661053 -H 'content-type: application/x-www-form-urlencoded' -d 'username=proxmox&password=KEYCLOAKPASSWORD&grant_type=password'

La requête doit renvoyer un access token en JSON

{"access_token":"eyJaaaaaaaaaaaaaaa90A","expires_in":300,"refresh_expires_in":1800,"refresh_token":"eyJaaaaaaaaaaaaaaa_Ks","token_type":"Bearer","not-before-policy":0,"session_state":"f68a1fcc-7741-4ba7-bea6-51756e81f6e1","scope":"profile email"}

Installer Keycloak 15 sur Ubuntu 20.04 (sans Docker)

Mon, 30 Aug 2021 06:30:00 +0000

Keycloak sur Ubuntu, pour faire de l’OIDC comme un chef

J’en ai parlé un peu lors de l’article sur les soucis que j’ai rencontré lors de mon passage de Proxmox VE 6 à 7 : une des features (surprise en plus) de cette release a été le support d’OpenID Connect pour l’authentification dans Proxmox VE.

Ça fait très longtemps que j’ai envie d’ajouter une authentification externe de type SSO à mon cluster Proxmox VE perso, mais je n’ai pas eu le courage (l’envie) d’installer un LDAP et encore moins un Active Directory (heureusement cette période de ma vie est loin derrière).

Or, je sais que dans les produits permettant de faire de l’OpenID Connect (et du SAML), il y a Keycloak, le IAM récupéré par Redhat et qui cartonne pas mal depuis quelques années maintenant.

Add authentication to applications and secure services with minimum fuss. No need to deal with storing users or authenticating users. It’s all available out of the box.

You’ll even get advanced features such as User Federation, Identity Brokering and Social Login.

Et il se trouve aussi que j’ai pour plan d’installer, dans les jours / semaines / mois qui viennent un keycloak au boulot pour d’autres besoins qui n’ont rien à voir. Vous me voyez donc venir, j’ai pris les devant et j’ai installé keycloak sur mon infra perso ;-)

Note : dans cet article, on ne va parler que de l’installation de Keycloak. S’il n’y a que ça qui vous intéresse, ne vous inquiétez pas, la partie Proxmox sera traitée dans un autre article.

Pourquoi pas un container Docker ?

La plupart des gens installent keycloak de la façon qui est maintenant mise en avant par beaucoup d’éditeurs quand leur soft est un peu pénible à installer : un container Docker.

Effectivement ça simplifie grandement l’installation, surtout comparé à la doc d’install sans docker qui est pas terrible terrible…

For more details go to about and documentation, and don’t forget to try Keycloak. It’s easy by design!

easy by design ??? p%$$£ç*µ !!!

Alors qu’avec Docker, l’image est prête à l’emploi et « juste marche » (pour peu qu’on sache à peu près faire de l’OIDC ce qui n’était pas mon cas mais ça c’est une prochaine histoire ;-p).

docker run -p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin quay.io/keycloak/keycloak:15.0.2

Et donc du coup, nous on va l’installer à la mano

Eux disent que c’est une installation « baremetal ». Enfin, ça, c’est leur terminologie à eux. Moi je vais l’installer dans un container LXC, mais ça aurait très bien pu être installé sur une « vraie » VM Linux, un serveur physique ou un raspberry Pi (des gens l’ont porté sur ARM avec succès).

Keycloak est relativement peu gourmand (surtout pour une application Java !!) et tourne sans broncher dans mon container LXC avec 512 Mo de RAM. Je suis certain que j’aurais pu mettre moins en tweakant la JVM.

L’installation « baremetal » donc se base sur un serveur Wildfly à faire tourner sur un OpenJDK > 8. Une fois mon container LXC (ou ma VM) installée en Ubuntu 20.04, j’ai donc installé le dernier JRE disponible (16)

apt update
apt dist-upgrade
apt install openjdk-16-jre
java -version
openjdk version "16.0.1" 2021-04-20
OpenJDK Runtime Environment (build 16.0.1+9-Ubuntu-120.04)
OpenJDK 64-Bit Server VM (build 16.0.1+9-Ubuntu-120.04, mixed mode, sharing)

Dans les autres prérequis que je m’impose moi-même, c’est la création d’un utilisateur Linux non privilégié (ne pas lancer un soft en tant que root sauf si c’est vraiment nécessaire !)

groupadd keycloak
useradd -r -g keycloak -d /usr/lib/keycloak -s /sbin/nologin keycloak

Récupérer la dernière version

Redhat package son soft dans un tar.gz disponible sur github dans la section releases de dépôt principal de keycloak. Vous trouverez aussi des raccourcis sur cette page. Dans mon cas, je n’ai pas essayé encore la version Quarkus (en preview) mais bien la bonne vieille version Wildfly.

cd /usr/lib
wget https://github.com/keycloak/keycloak/releases/download/15.0.1/keycloak-15.0.1.tar.gz
tar xzf keycloak-15.0.1.tar.gz
ln -s keycloak-15.0.1 keycloak
rm keycloak-15.0.1.tar.gz
chown -R keycloak: /usr/lib/keycloak-15.0.1
chmod o+x /usr/lib/keycloak/

Configuration

A partir de là, on a quasiment tout pour démarrer le serveur Keycloak. En vrai, on pourrait déjà lancer le script standalone.sh et ça démarrerait.

Mais ça ne marcherait pas très très bien, car on a pas mal de configuration à faire. Ce genre de procédure cracra m’a rappelé la bonne époque de configuration des produits Redhat et IBM (maintenant la même maison, comme par hasard) qui fleure bon la prise de tête et les erreurs humaines…

La première chose à faire est de créer quelques dossiers et de copier des fichiers :

mkdir /etc/keycloak
mkdir -p /var/run/keycloak
chown keycloak: /var/run/keycloak
cp /usr/lib/keycloak/docs/contrib/scripts/systemd/launch.sh /usr/lib/keycloak/bin/
cp /usr/lib/keycloak/docs/contrib/scripts/systemd/wildfly.conf /etc/keycloak/keycloak.conf
cp /usr/lib/keycloak/docs/contrib/scripts/systemd/wildfly.service /etc/systemd/system/keycloak.service

La « blague » c’est que les PATH sont rentrés en durs dans la plupart de ces fichiers et pointent vers « /opt/wildfly » ce qui a peut-être beaucoup de sens pour les gens de chez Redhat mais pas dans mon setup (j’installe keycloak, pas un serveur wildfly, dans /usr/lib, pas dans /opt…).

Comme je suis feignant et que je crains les fautes de frappes difficiles à voir à l’œil nu, j’édite les fichiers incriminés avec des sed. Mais libre à vous de préférer les éditer à la main avec vi (d’ailleurs, ça vaut le coup de vérifier que le fichier est pas en vrac).

sed -i 's!wildfly!keycloak!g' /etc/systemd/system/keycloak.service
sed -i 's!/opt/keycloak!/usr/lib/keycloak!' /etc/systemd/system/keycloak.service
sed -i 's!/opt/wildfly!/usr/lib/keycloak!' /usr/lib/keycloak/bin/launch.sh
#lire la suite avant de lancer la suivante
sed -i 's!\$3$!\$3 -Dkeycloak.frontendUrl=https://keycloak.example.org/auth!' /usr/lib/keycloak/bin/launch.sh

Petite subtilité pour la dernière commande sed, j’ai mis keycloak derrière un reverse proxy pour faire plus joli et ajouter une couche TLS gérée par moi (et pas par wildfly) et arrêter de faire du PLAIN sur un soft d’IAM (facepalm).

(lien mort, je ne suis plus sur Twitter)

Sauf que la totalité liens sur les pages d’admin de keycloak pointaient en HTTP plain qui échouaient donc.

La solution dans ce genre de cas est décrite ici et en gros le plus simple c’est de coller l’URL de votre frontend / reverse proxy dans les paramètres de lancement. Pourquoi faire simple quand on peut faire compliqué ?

Démarrer le service

A partir de là, on a quasiment un keycloak vraiment fonctionnel. Vous pouvez lancer la console :

systemctl enable keycloak.service
systemctl start keycloak.service

La console est accessible sur votre LAN via l’IP de la VM sur le port 8080

Reste la dernière petite subtilité : il n’y a aucun compte pour s’y connecter :trollface:.

On retourne dans notre shell et on lance le script suivant, qui va injecter un bout de XML dans notre conf (qu’est ce que c’est crade… heureusement que le soft est bien au-delà de l’install…)

/usr/lib/keycloak/bin/add-user-keycloak.sh -r master -u youruser
Press ctrl-d (Unix) or ctrl-z (Windows) to exit
Password:
Added 'youruser' to '/usr/lib/keycloak/standalone/configuration/keycloak-add-user.json', restart server to load user

Ah, et bien sûr, comme c’est de la configuration XML en dur, il faut redémarrer wildfly ;-)

systemctl restart keycloak.service

Et maintenant, à partir de là, vous pouvez commencer le “Getting Started”.

Déléguer l’authentification Gitlab à Azure AD avec OAuth2

Tue, 14 May 2019 11:45:56 +0000

Gérer les comptes internes à Gitlab, c’est bof, le SSO, c’est mieux !

Dans le cadre de l’hébergement d’un nouveau serveur Gitlab, j’ai voulu intégrer notre base de compte existante, synchronisée dans Azure à l’aide de l’outil Azure AD, qui est le pendant « cloud » de l’Active Directory, bien connus de mes amis Windowiens (oui, il y en a). La plupart des applications savent aujourd’hui déléguer l’authentification à des fournisseurs tiers, généralement de type LDAP, via des protocoles tels que SAML(2) ou OAuth(2).

Cependant, bien que ces protocoles soient standards, leur implémentation dépend fortement du logiciel en question et il n’est pas toujours facile de s’y retrouver.

Pour faciliter cette opération, Azure a mis à disposition, directement dans Azure AD, des objets préconfigurés pour des milliers d’applications tierces. C’est comme ça qu’on peut implémenter, de manière simple et rapide, le SSO Active Directory avec les produits Atlassian (JIRA + Confluence), par exemple.

Tout commence dans Azure

Dans le portail Azure, ouvrir « Entreprise applications », puis cliquer sur « New Application »

Malheureusement pour nous, il n’y a pas de template pour Gitlab ! Il va falloir le faire à la main.

A noter, le principe déroulé dans ce tutoriel est valable pour n’importe quelle autre application supportant des mécanismes similaire. Il est possible de réutiliser un template utilisé pour un soft et le réadapter pour d’autres logiciels qui fonctionnent de la même façon. C’est juste une histoire de paramètres.

Le menu nous conseille donc de choisir « Non-gallery application », puisque nous ne trouvons pas Gitlab. Sauf que, bizarrement, il faut un compte Premium pour utiliser cette feature.

On se rabat donc sur « Application you’re developing ». C’est d’ailleurs ce que conseille d’utiliser la documentation de Gitlab. Sauf que, pas de chance non plus, ça ne marche plus comme ça, maintenant ;)

Créer une App registration pour Gitlab

Pour toutes les applications qui ne sont pas dans le store, on ne peut donc plus passer par les « Entreprise Applications ». On va donc créer une « App registration », qui n’est ni plus ni moins qu’un compte de service avec un ID et un (ou plusieurs) secrets.

Cliquer sur « New registration », puis lui donner un nom.

Sélectionner le type de comptes qui pourront accéder à cette application. Dans mon cas, il s’agit uniquement d’autoriser les comptes provenant de mon AD, mais on peut imaginer le cas d’une application ouverte en BtoB ou carrément ouverte à tout Internet.

Enfin, renseigner l’URL de callback, qui permettra à Azure de rediriger l’utilisateur qui s’est authentifié avec succès vers notre Gitlab.

We’ll return the authentication response to this URI after successfully authenticating the user. Providing this now is optional and it can be changed later, but a value is required for most authentication scenarios.

Dans le cas précis de Gitlab, cette URL aura la forme : mongitlab.example.org/users/auth/azure_oauth2/callback

Récupérer des valeurs qui intéressent Gitlab

Retourner ensuite dans l’overview de notre nouvelle « App registration ». Dans les détails, elle dispose d’un Application ID, aussi appelé Client ID et d’un Tenant ID :

On va maintenant créer un Secret. Pour les secrets, on peut choisir soit d’uploader un certificat (conseillé car plus sécurisé), ou de lui générer un mot de passe. Pour la simplicité de ce tutoriel, je vais créer un mot de passe pour notre application, mais je le répète, mieux vaut uploader un certificat.

On dispose maintenant de notre CLIENT_ID, notre TENANT_ID et de notre CLIENT_SECRET. Notez les bien, car une fois que la fenêtre sera fermée, il ne sera plus possible de relire à nouveau le secret et il faudra en générer un nouveau…

Ajouter des restrictions ou des fonctionnalités complémentaires

En fonction de votre niveau de licence pour Azure AD, vous aurez accès à plus ou moins de choses. Moi, je n’ai accès à pratiquement aucune feature, mais si vous avez mieux, vous aller pouvoir ajouter des options très pratiques telles que le self service (les utilisateurs peuvent demander eux même à avoir accès à l’application, et si c’est validé, ils sont ajouté dans le bon groupe) et aux autorisations/restrictions par groupes Azure AD.

Pour se faire, il faut RETOURNER dans les Entreprises Applications (#RollingEyes), puis chercher notre « App registration » qui y apparaît maintenant dans la liste (avec le filtre All applications).

Configuration de Gitlab

Gitlab ayant été installé avec les packages, la configuration se situe dans le fichier /etc/gitlab/gitlab.rb.

Dans le fichier de configuration, ajouter le bloc suivant en remplaçant les valeurs en majuscules par celles qu’on vient de récupérer :

gitlab_rails['omniauth_providers'] = [
{
"name" => "azure_oauth2",
"args" => {
"client_id" => "CLIENT_ID",
"client_secret" => "CLIENT_SECRET",
"tenant_id" => "TENANT_ID",
}
}
]

Rechargez ensuite Gitlab pour prise en compte de ce nouveau paramètre

sudo gitlab-ctl reconfigure
[...]
Running handlers complete
Chef Client finished, 13/637 resources updated in 26 seconds
gitlab Reconfigured!

Une boite d’authentification Azure Oauth2 devrait apparaître sous le login classique !! Youpi :)

Et voilà c’est fini… ou presque…

Vous avez maintenant ajouté du SSO et l’authentification via Azure AD pour l’accès à votre Gitlab ! On essaye de se connecter ?

Et Paf !!

Signing in using your Azure Oaut2 account without a pre-existing gitLab account is not allowed

En fait, c’est normal.

Par défaut, il n’est pas possible de s’authentifier avec Azure Oauth2 si un compte n’existe pas préalablement dans Gitlab, ce qui est quand même bien dommage si vous avez beaucoup de comptes à créer.

Deux cas de figure.

Soit vous ne souhaitez pas que n’importe qui dans votre AD puisse se connecter sans votre accord préalable

Dans ce cas là, ce cas vous est finalement assez favorable, puisque vous allez pouvoir explicitement dire qui peut ou ne peut pas se connecter. Si vous ne disposez pas des bonnes licences et que vous avez pas pu restreindre l’accès à un groupe d’utilisateurs, c’est une « solution » de contournement acceptable.

Cependant, pour éviter de créer à la main tous les comptes, il sera probablement préférable de les créer de manière automatique à l’aide de l’API Gitlab et même du très bon module Ansible gitlab_user :

- name: "Create Gitlab User"
gitlab_user:
server_url: "{{gitlab_api}}"
login_token: "{{token}}"
validate_certs: True
name: "Zwindler"
username: "zwindler"
password: "{{ 99999999 | random | to_uuid }}"
confirm: no
email: "zwindler@zwindler.fr"
state: present

Soit, à l’inverse, vous souhaitez que tous les utilisateurs de votre AD puissent avoir accès, sans pour autant devoir les ajouter uns par uns

Il existe alors des lignes sont à ajouter dans la configuration gitlab pour autoriser cette option :

gitlab_rails['omniauth_allow_single_sign_on'] = ['azure_oauth2']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['sync_profile_from_provider'] = ['azure_oauth2']
gitlab_rails['sync_profile_attributes'] = ['name', 'email']

D’un point de vue sécurité, c’est un peu moins bien puisque n’importe qui avec un compte pourra se connecter, sans que vous le sachiez.

Cependant, ce problème est un peu moins grave qu’il n’y parait puisque l’utilisateur sera logué mais n’aura accès à rien (ou juste ce qui est « public »).

Dans le cas d’un Gitlab d’entreprise, où tous les développeurs doivent pouvoir se connecter, cette seconde option me parait quasi obligatoire. C’est encore plus acceptable si vous avez pu restreindre l’accès au SSO par groupe dans Azure AD, comme indiqué plus haut.

Have fun :)