Le prochain défi du SSO ( signle sign on): faire simple

Le principe du SSO date maintenant d'une bonne dizaine d'année. j'ai travaillé sur lemonldap puis le projet lemonldap::NG (NG pour Nouvelle Gendarmerie et non pas Next Generation)  a pris la suite. Mais depuis, il n'y a rien de vraiment innovant dans ce domaine. La gestion d'identité devait etre un élément stratégique pour les editeurs , les frameworks , les entreprises et les fournisseurs d'identité. Tout ça est retombé comme un soufflet à la guimauve. Chacun compte ses pertes sur le champ de bataille. Que reste-t-il de tout ca ?

Les fournisseurs d'identité et les protocoles: les grands vainqueur sont les sites offrant des services d'authentification basés sur le protocole oauth : exit liberty alliance et SAML. Tous les grands sites comme facebook , twitter, google ont emboité le pas à ce protocole.

Les parefeux applicatifs: on reste sur des équipements en frontal à base d'apache ou de  tomcat  (rupture de flux) ou en service de redirection  (CAS).

Le service d'authentification: S'authentifier auprès d'un annuaire LDAP est cohérent dans la mesure où les équipements les plus hétérogènes peuvent dialoguer avec un service LDAP. En revanche , utiliser un annuaire LDAP comme stockage  d'habilitation est une solution  inadaptée.  Une base de données est plus performante pour cela , notament grace à la puissance du SQL.

Devoir utiliser deux systèmes (LDAP et base de données)  pour rendre le service du SSO est génant. Les administrateurs systèmes préfèrent ne gérer qu'un seul type d'équipement. C'est pour cette qu'un système de stockage NoSQL peut tirer son épingle du jeu.

La mise en place d'un SSO au sein d'une entité reste une opération compliquée, intrusive et structurante. Le SSO introduit un point de  fragilité dans les architectures.  Il faut des serveurs , le plus souvent doublés: tout cela coute cher  et rend  les applications interdépendantes.

Les SSO sont des constructions délicates et réservées aux experts. 

Illustration: machine de Rube Golberg

Est ce qu'il ne serait pas possible de faire des systèmes de SSO SIMPLE ? 


La réponse est : OUI

Le cross domain authentification ou comment envoyer un cookie d'un domaine à l'autre

Pour maintenir une session le protocole du web (HTTP) ne prévoit pas vraiment de mécanisme. Il faut pour cela utiliser les cookies (RFC 2109). Mais un cookie par mesure de sécurité ne relève que d'un seul domaine. Le client (navigateur) ne doit accepter des cookies que pour le domaine de l'url consultée. Et il ne doit les présenter que sur le domaine en question.

Alors comment passer un cookie d'un domaine à l'autre ?. Cette opération peut etre 'légale' dans un but de propagation d'information (authentification ou autre) ou illégale afin de capturer les cookies.
Dans les deux cas la technique est un peu similaire.

Le serveur web sur le domaine appli.domainA qui veut récupérer le cookie déposé par appli.domainB (donc un domaine diffèrent) va dans une des pages de l'appli.domainA inserer un lien vers une ressource de appli.domainB. Pour que le processus soit invisible pour l'utilisateur on utilise souvent un lien vers une image de taille de 1 pixel. Le gestionnaire de l'appli.domainA doit évidemment avoir accès à la location sur domainB qui héberge cette image pour enregistrer les cookies.

L'autre méthode utilisée pour propager la session d'un domaine à un autre est le cross domain authentification: Le site domainA qui veut passer la valeur de son cookie à domainB va réaliser une redirection de domainA vers domainB en passant en paramètre la valeur de son cookie , comme par exemple :
get http://appli.domainB/service?cookiesurdomainA=valeur.

Cette technique pose plusieurs problèmes:

Quel est le nom du paramètre, de l'url du service , du mode d'encodage et sur quelle url rebrancher l'utilisateur.

Les protocoles Oauth , openID servent à normaliser tout ceci.

Temps d'inactivité.

Dans un système où un utilisateur travaille sur 5 domaines, on peut imaginer un dispositif de controle du timeout (temps d'inactivité ) de la session.
Chaque domaine dépose un cookie mis à jour à chaque sollicitation.
En ca de timeout détecté par un domain , il interroge successivement les autres domaines pour collecter l'état du compteur inactivité. En fonction du résultat collecté , le serveur valide ou invalide le timeout. L'url servant de support aux interrogations serait de la forme : get http://serveur.domainSuivant/timeout?cookiedomainA=30min&cookiedomainB=0 etc.
Il est plus facile de réaliser ce montage en définissant un domaine maitre et des domaines esclaves.

Le processus de connexion pourrait etre le suivant :



dans l'implementation du Lemonldap le CDA est construit sous la forme d'une redirection:

print CGI::redirect($controlslave."?op=$session_id&url=".$urlc);

Qui va donner : http://serveur.domaine?op=valeur_cookie&url=url_de_retour

Un bricolage sur un coin de table

Un des premier prototype avec l'ancien nom : Levon et la distribution mandrake.
J'avais déja adopté un numérotation à 3 chiffres.

La mire de la version accélerateur Internet : 6 serveurs en lignes sous Debian.



Ce matin les chiffres sont tombés : 5076 utilisateurs s'étaient connectés hier sur le portail Internet de la DGFiP(ex DGCP), c'est pour nous un jalon. Ce dispositif permet aux partenaires de la DGFiP (ordonnateurs: Maires, Départements , Régions, Etablissemnts Publics) et aux agents d'accéder de manière sécurisé (certificat client) au frontal du système informatique de la DGFiP. Le composant Lemondap est la clé de voute de cet édifice, aidé par apache, Mod-Perl , Perl, memcached et openldap. C'est un reverse-proxy 'tête de pont" qui en fonction de l'URL, mandate des applications métiers. C'est un système global car il couvre les fonctionnalités allant de la délivrance des certificats clients, jusqu'à l'alimentation d'un entrepôt de données avec les log Apache. Cet entrepôt sert de base aux différentes restitutions en mode texte, graphique avec openChart et mail. L'entrepôt de données est basé sur une base PostgreSQL hébergeant des tables dénaturées préfigurant les bases de données vectorielles (voir le concept des bases vectorielles).

Ce projet est né vers 2002 , il a plusieurs branches : Lemonldap::NG (Nouvelle Gendarmerie) basé sur les Threads Perl, Un packaging Interne (basé sur une RedHat) appelé DAC, servant à la télédéclaration (7 millions d'utilisateurs).La version d'origine est là sur le cpan.org
Projet récompensé par un prix:

Je voulais remercier Arnaud, alexandre ,Casimir , le personnel des centres de Lyon, Versailles et Marseille. J'aimerais croire que dans notre nouvelle structure, un tel projet soit encore possible. Mais la réponse ne m'intéresse pas, je suis passé à autre chose. L'économie globale pour le contribuable se mesure en KE (déjà 100 ke pour la partie serveur applicatif).


Que devrait etre une nouvelle version de Lemonldap ?. Déjà le socle resterait du Debian qui est la meilleure distribution avec le meilleur système de package (elle sert de base à UBUNTU) .
Le serveur HTTP serait soit NGINX qui offre la meilleure et la plus simple API C de développement, soit un dérivé de Yaws qui est un serveur HTTP écrit en Erlang.
CouchDB remplacerait le serveur de session memcached.
La partie alimentation de l'entrepôt resterait la même (écrite en C).
Malgré mon changement d'orientation, je reste un développeur dans l'âme. Au lieu d'écrire du code , je rédige des clauses de marché , des notes. Quelque part c'est aussi de la technique. Les leviers du pouvoirs sont ailleurs, sur des terres hostiles et je dois progresser camouflé pour imposer la:

Prochain jalon: 10.000
Heureusement j'ai ce blog comme exutoire....

Lemonldap :Top 10 des projets

Lemonldap est dans le top 10 des projets francais opensource  (selon la revue l'informaticien avril 2009). J'ai pris connaissance de cette nouvelle au cours du salon solution linux 2009. Plusieurs personnes sont venues  me présenter leurs félicitations, c'était très sympathique.

La photo :
 

Nouveau projet

Je lance un nouveau projet :

http://code.google.com/p/lemonid/

Sa description :

Lemon-id is digital identity manager integrator based on Rails , Database and LDAP

Ses objectifs:

Lemon-id n'est pas un nouveau projet de gestion d'identité numérique. Il a pour but d'intégrer les autres projets de web SSO ,d'authentification dans un framework fournisseur d'identité. Lemon-id servira de base d'authentification à d'autres composants et pour cela il proposera plusieurs interfaces.

Ses principes :

* Une base de données pour les Meta-données
* Fichiers de configuration au format YAML
* Format JSON pour les échanges entre les composants
* Interface graphique en Rails

Nouvelle technique de reverse proxy

Le reverse proxy du portail dgfip https://portail.cp.finances.gouv.fr ou https://portail.dgfip.finances.gouv.fr (pour le ranking) est basé sur un serveur https qui analyse la suite de l'url
Exemple :
nom_du_serveur/foo correspond à une location 'foo' qui a ses propres regles de gestion. La présence de 'foo' dans l'url permet au serveur de choisir la bonne application cible. Toutes les applications ne travaillent pas sur une location, pour celles-ci il faut 'chrooter' l'application au niveau du serveur reverse proxy. Cette opération lourde nécessite un travail fastidieux de rééecriture dynamique des liens.
Ce processus est complété par une bonne dose de mod_rewrite pour les derniers ajustements.
Ainsi il serait plus simple d'abriter les applications derrière le reverse proxy.
Pour cela je serai tenté d'essayer la solution suivante:
Une page menu des applications qui au lieu de proposer un lien , provoquerait la pose d'un cookie contenant le nom de l'application à activer.
Le tout serait peut être à compléter avec mod_rewrite et des tests sur le referer.
Le système ne permettrait pas d'avoir plusieurs applications ouvertes simultanément et il faudrait repasser par le menu pour ouvrir une autre application.
Il faut avoir non pas une page menu mais une application menu. Les liens sont remplacés par des boutons de formulaires qui par un POST provoquent la génération d'un cookie au nom de l'application et la sélection de celle-ci.
L'url de la page menu doit être traitée de manière particulière : elle n'appartient pas à une application. Je ne suis pas certain qu'apache soir capable de travailler de cette façon (sans véritable location) .

Test de replication d'un serveur memcached

Pour mettre en place la réplication d'un serveur memcached ,il faut :
- Le source de memcached
- Le patch repcached à appliquer


Sur le site du projet repcached on trouve à la fois le patch mais aussi le source memcached patché.

Pour appliquer le patch :

Aller dans le répertoire supérieur de memcache et lancer la commande :
patch -p0 < 'le_nom_du_fichier_patche'

Puis aller dans le répertoire des sources memcached et taper :
./configure --enable-replication
make && make install

Dans le répertoire source se trouve l'executable memcached et la commande :

./memcached -v -u root

donne la ligne :
replication: listen

Confirmé par un netstat -a|grep LIST

tcp 0 0 *:11211 *:* LISTEN
tcp 0 0 *:11212 *:* LISTEN

Le port 11212 sera utilisé par la réplication

Si on relance memcached en très verbeux on peut suivre les connexions :
./memcached -vv -u root

<6 server listening (replication)
replication: listen
<7 server listening
<8 send buffer was 109568, now 268435456
<8 server listening (udp)

Je lance une deuxième instance de memcached sur un port différent :
./memcached -u root -p 11310 -x localhost -vv
Les lignes en sortie donnent :

replication: connect (peer=127.0.0.1:11212)
<6 new client connection
<7 new client connection
<8 new client connection
replication: marugoto copying
<6 marugoto_end
<9 server listening
<10 send buffer was 109568, now 268435456
<10 server listening (udp)
replication: start


Dans la première console s'ajoute les lignes :

replication: accept
<6 connection closed.
<9 new client connection
<6 new client connection
<10 new client connection

Ainsi le premier serveur est en relation avec le deuxième
L'ajout d'une session sur le deuxième serveur est répercuté sur la premier serveur
(deuxième serveur)
<11 new client connection
<11 set fac097f7fb944ea33b7fb2f31b45b9b4 1 0 56
>11 STORED
<11 set fac097f7fb944ea33b7fb2f31b45b9b4 1 0 94
>11 STORED

(premier serveur)
<9 rep fac097f7fb944ea33b7fb2f31b45b9b4 1 0 56 1
REP>9 STORED
<9 rep fac097f7fb944ea33b7fb2f31b45b9b4 1 0 94 2
REP>9 STORED

Le seul mode disponible est donc le mode master/master

Si on coupe un serveur et qu'on ajoute des entrées sur l'autre , au redémarrage du serveur stoppé , les lignes suivantes vont s'afficher :
replication: marugoto start
replication: marugoto 7
replication: marugoto owari

(l'auteur est japonais et aime le manga !! )

Le serveur qui est resté en marche envoie les données que le serveur stoppé n'a pas enregistrées.

Ainsi se dispositif réalise à la fin la synchronisation ET la restauration des sessions .
Les nouvelles options de réplications ne sont fournies qu'a la deuxieme instance par les paramètres : -x host_de_l_autre_serveur -X port de réplication (defaut 11212) comme l'indique l'option -h (help)
-x hostname or IP address of peer repcached
-X TCP port number for replication (default: 11212)

L'avantage de ce dispositif est qu'il est intégré à memcached et qu'il propose un système de resynchronisation.

Serveur de session memcached: replication des sessions

J'utilise une architecture de gestion de session a base de memcached . Nativement les clients memcached savent repartir la charge sur plusieurs serveurs. Reste, le problème de la chute d'un serveur memcached qui provoquera la perte des sessions hébergées par ce serveur. J'ai développé il y a quelques temps un système de réplication des sessions memcached basée sur les log (mode verbeux --vv ) . Un script Perl va lire ce fichier et rejoue les opérations sur un ou plusieurs serveurs memcached . Ainsi plusieurs serveurs sont synchronisés en temps réel.
J'avais prévu un mode 'maitre-esclave' et un mode 'maitre-maitre' . Sur fresmeat le projet repcached communique sur un patch pour mecached qui lui ajoute des fonctions de réplication.

C'est une excellente nouvelle et je prévoit des tests sur le produit.