Cet article est le premier d’une série qui va expliquer en détails la conception et les choix architecturaux de l’application de test fournie sur https://github.com/jp-gouigoux/TestOIDCBlazorWASM.
Après avoir écumé de nombreuses ressources sur internet ou dans des livres techniques montrant chacune des bouts ou des implémentations approximatives de pans architecturaux, je souhaitais brancher tous ces éléments les uns avec les autres et créer une sorte d’architecture modèle de ce que j’avais en tête. L’application avait pour but de montrer un assemblage à peu près correct des technologies suivantes :
- Blazor WebAssembly
- API ASP.NET Core
- Authentification OpenID Connect avec JWT
- Authentification JWT avec tokens séparés pour le client (ID Token) et le serveur (Access Token)
- Implémentation de l’identity provider avec KeyCloak, pour amener à un bon niveau d’indirection de l’IAM
- Gestion des rôles pour les autorisations
- Sécurité en rideaux, avec blocages multiples au niveau du client et sécurité sur le serveur basée sur les mêmes données uniques - d’utilisateur
- Conception dans l’esprit RBAC, avec une séparation des groupes et des rôles
- Gestion asynchrone de certains traitements complexes, grâce à une file de messages RabbitMQ
- Génération de PDF en code
- Déploiement en Docker des dépendances (celui pour les modules principaux sera réalisé par la suite)
- Persistance découplée, avec les données dans une base de données MongoDB et les documents dans une GED CMIS, en l’occurrence Nuxeo
- etc.
Ces technologies et cette architecture ont été définies avec des critères d’industrialisation de l’approche, pour mettre en œuvre les principes de découplage et de séparation correcte des responsabilités dans une approche de services (voire microservices dans leur compréhension en tant qu’outils d’évolutivité simplifiée des applications complexes). Le fonctionnel n’a aucune importance et est volontairement fortement simplifié pour ne pas perturber l’analyse sur les caractéristiques techniques de l’ensemble.
Tout n’est pas encore finalisé, mais une première version a été publiée (https://github.com/jp-gouigoux/TestOIDCBlazorWASM/tree/v1.0.0) qui comprend la majorité des points de difficulté qui étaient attendus.
Les articles qui suivront traiteront chacun d’une partie de l’application, et tenteront de donner le maximum de détails à chaque fois pour reproduire cette application dans sa version actuelle à partir du modèle “vide” produit par Visual Studio. Mon but est que chaque ligne additionnelle soit expliquée en détails, car j’ai passé trop de temps à essayer de comprendre le pourquoi derrière de nombreux articles sur internet qui donnaient juste le code qu’il fallait entrer pour que ça marche, sans fournir d’explication. Le problème de cette approche est que, lorsque les versions ou les contextes changent, il est compliqué d’adapter si on n’a pas compris ce qui se passe derrière.
Le rythme de publication espéré est d’un article par semaine environ (hors congés) et j’imagine qu’il en faudra une petite dizaine pour arriver au bout de l’explication complète à l’issue de laquelle les lecteurs seront normalement en mesure de recréer entièrement l’application, et ce dans leur propre contexte (GED CMIS différente, fournisseur d’identité OIDC différent, etc.).
EDIT avril 2023 : le rythme effectif est malheureusement bien inférieur à celui espéré, car de nombreuses contraintes professionnelles ou d'autres projets sont passées devant cette série d'articles. Elle n'est toutefois pas arrêtée et le passage sur un blog statique devrait aider à aller plus vite à produire la suite. Etre poussé par l'utilité potentielle de certains sujets dans le cadre de projets professionnels motive également, ces articles ayant aussi pour but de servir d'explication détaillée des architectures mises en place à mes chers collègues.