index.md 4.2KB
title: Stratégies SSO slug: strategies-sso date: 2015-05-14 chapo: Il faut bien être conscient de ces limitations, c’est le coût de la généricité et de la décentralisation.
Je ne rêve pas d’un monde où la religion n’aurait plus de place, mais d’un monde où le besoin de spiritualité serait dissocié du besoin d’appartenance. D’un monde où l’homme, tout en demeurant attaché à des croyances, à un culte, à des valeurs morales éventuellement inspirées d’un Livre saint, ne ressentirait plus le besoin de s’enrôler dans la cohorte de ses coreligionnaires. D’un monde où la religion ne servirait plus de ciment à des ethnies en guerre. Séparer l’Église de l’État ne suffit plus ; tout aussi important serait de séparer le religieux de l’identitaire. Et, justement, si l’on veut éviter que cet amalgame ne continue à alimenter fanatisme, terreur et guerres ethniques, il faudrait pouvoir satisfaire d’une autre manière le besoin d’identité.
Ce qui me ramène à mon interrogation initiale : par quoi pourrait-on remplacer aujourd’hui l’appartenance à une communauté de croyants ?
Les identités meurtrières, Amin Maalouf
On travaille avec Vincent sur une stratégie de Single-Sign On (authentification unifiée) pour la communauté encommuns qui développe des briques pour faciliter le développement d’un « commun libre » et expérimente des moyens de rémunération atypiques.
Vouloir faire du SSO implique plusieurs responsabilités :
- une contrainte de disponibilité : si ce service tombe, tous les autres deviennent inaccessibles ;
- une contrainte de sécurité : si ce service se fait hacker, ça introduit une faille dans tous les autres ;
- une contrainte de confidentialité : celui qui a accès à ce service sait où chaque personne s’identifie en temps réel.
Nous avons au départ exploré des solutions simples comme CAS avec django-mama-cas pour la partie serveur (ce nom <3) et django-cas-ng pour la partie client (rien à voir avec angular) mais cela ne convenait pas à la dynamique que souhaite imprimer la communauté avec des outils décentralisants.
On a donc cherché des solutions qui ne soient pas centralisées. Ce qui ajoute des contraintes :
- le profil d’un utilisateur va devoir être distribué/répliqué pour chaque service car il ne peut se baser que sur le plus petit dénominateur commun — généralement email et nom/identifiant — des services d’authentification tiers (à moins d’encourager les plus gros en faisant un traitement particulier) ;
- les performances sont affectées avec les redirections distantes inhérentes à la nature décentralisée de l’authentification, cela peut être non négligeable en cas de connectivité réduite ;
- l’authentification en devenant tierce fait peser certaines des responsabilités précédentes sur les épaules d’autres équipes qui n’ont pas forcément les mêmes objectifs en terme de profilage ou de monétisation.
Il faut bien être conscient de ces limitations, c’est le coût de la généricité et de la décentralisation. Cela questionne la confiance que vous pouvez avoir dans des services que vous ne contrôlez pas pour un sujet aussi critique que l’authentification, c’est loin d’être anodin.
Il y a plusieurs solutions pour faire du décentralisé et dommage que le projet Persona ait été abandonné par Mozilla car c’était un sérieux candidat. Nous avons au final opté pour django-oauth-toolkit qui est vraiment très bien documenté associé à python-social-auth. À noter des initiatives comme NickNym ou WebID.
Merci à Simon, Freddy et Olivier pour leurs réflexions et expériences.