Capitole du Libre 2022

Paramètres par défaut ou documentation ? Les limites du "getting started" en un clic. Exemples avec Keycloak
20 nov. , 11:00–11:30 (Europe/Paris), A002

"docker run", "localhost:8080" et vous avez de suite quelque chose de fonctionnel. Prêt à partir en production ? Absolument pas ! 2 approches diamétralement opposées :
- faire en sorte que tout fonctionne le plus rapidement possible (paramètres par défaut)
- documenter, en long en large et en travers tout en accompagnant l'utilisateur

Après avoir déployé des dizaines de Keycloak en production pour nos clients, nous verrons ensemble les limites des deux stratégies et surtout comment cela peut s'avérer extrêmement dangereux jusqu'à des services officiels Français.


Le "getting started" simple par excellence : docker run
pas de base de données, inmemory ou infile
pas de SSL
Aucune optimisation

Pourtant on le sait tous, ce sont des configurations qui peuvent se retrouver en production beaucoup plus de fois qu'on ne le pense.
Parcourrons ces problématiques avec pour exemple la référence du SSO opensource : Keycloak

Après 8 ans en tant que DevOps dans les univers du Cloud et de l’IOT, j’ai découvert la nécessité absolue de bien faire l’authentification sur les applications. Depuis 4 ans, j’ai décidé de ne faire que ça avec please-open.it. N’oublions jamais que nous faisons des logiciels pour des utilisateurs finaux, seul l’usage prime.

Je suis un développeur experimenté un peu touche à tout, j'ai choisis avec please-open.it d'approfondir le sujet de l'authentification et plus largement les architectures de roles et la sécurisation des SI.
Je me suis aperçu au fil des années que ces sujets, souvent considérés comme annexes, sont en fait primordiaux et se révèle souvent bloquant pour la croissance des entreprises. Nous remettons l'experience utilisateur au cœur de la sécurité pour prévenir la mise en place de solutions de contournement par les utilisateurs.