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

Comment choisir son Single Sign On (SSO)

On distingue généralement deux types de SSO: les SSO coopératifs et les SSO préemptif
Les SSO coopératifs sont des serveurs d'authentification qui délivrent des tickets directement à des utilisateurs ou indirectement à des proxy (mandataires) . Ces tickets sont à présenter aux applications qui les valideront auprès du serveur d'authentification.
Après validation l'utilisateur est connecté directement à l'application.

Les SSO préemptifs sont des pare-feux applicatifs , qui se placent devant les applications à protéger. Les flux utilisateurs doivent être dirigés vers ces équipements par le biais d'une résolution DNS ou par routage. Tous les flux (pages HTML, CSS, images) passent par ce dispositif. Les flux utilisateurs sont arrêtés , analysés puis le SSO activera ses fonctionnalités de Reverse proxy pour solliciter les applications à la place des utilisateurs.

Avantages serveur SSO coopératifs :
* Simples à mettre en ouvre
* Point de contrainte ou de contention faible
* Fonctionnent en natif sur plusieurs domaines
* Evolution vers la fédération d'identité
* Peu intrusifs vis à vis des applications
* Standardisés

Inconvénients
* Pas de gestion centralisé du time-out
* Pas de filtrage des flux applicatifs
* Pas de propagation d'habilitation

Avantages serveur SSO préemptifs :
* Centralisation pour filtrage des flux
* gestion centrale du time-out
* Propagation des habilitations
* Sécurisation des flux
* Mandataire

Inconvénients
* Complexe à mettre en place
* Fragilise l'architecture: SPOF
* Impact sur les performances
* Pas de gestion multi-domaine simple
* Impact sur la construction d'une application
* Non standard


Alors quel SSO choisir ?

La réponse est fonction du type d'architecture applicatives: SOA ou ROA (orientée ressource : REST) , de besoins de connexion depuis l'extérieur.
Il reste une solution : le lemonldap-CAS qui fait à la fois serveur CAS et Rupture de Flux permettant ainsi de mixer les applications.





Synthèse : clic pour élargir

gigya : l'api des apis.

Le site Gigya propose une API qui permet de s'authentifier sur les sites sociaux suivants:

MySpace   Facebook Yahoo   Friendster
Orkut          Bebo   WordPress  Blogger
Hi5          Tagged  LiveSpaces  Piczo
Freewebs  Livejournal  BlackPlanet  MyYearbook
TypePad  Xanga  Multiply  iGoogle
Netvibes  Pageflakes  MiGente  Vox
Ameba         Livedoor  Eons  overblog

Par l'ajout du composant visuel sur votre site, vos utilisateurs pourront s'authentifier aupres de leurs site habituel. C'est en fait une API qui vient en surcouche de 12 autres API (Facebook,yahoo etc)



Outre le service d'authentification Gigya propose des interactions avec certains sites comme facebook.

Un article dans Rails magazine n° 5 détaille son utilisation dans Ruby on Rails.

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....

Gerer ses mots de passe avec clipperz

La multiplication des mots de passe nous oblige à faire d'excellent effort de mémorisation. Heureusement il existe des solutions plus fiables.

Un document de type tableur hébergé par sur site (le mode le plus utilisé de nos jours)
L'utilisation d'un hébergeur de mots de passe comme clipperz

Sur ce site ici clipperz.com il est possible de stocker ses mots de passe et ses profils.
Le site propose une option de consultation en mode déconnectée votre fichier de mot de passe

Il reste maintenant à savoir si ce site est digne de confiance.

One Time Password , 3 secrets et compagnie avec yubikey La firme yubico

La firme yubico produit une clé USB délivrant à chaque utilisation un mot de passe jetable (OTP).
L'utilisateur ne paye que la clé, le service d'authentification est gratuit , les librairies sont libres.

Et en plus, on peut s'en servir de porte-clé !




Lorsque la yubikey est sollicitée , elle génère un token de 44 octets qui prennent la forme d'une chaine de caractère qui serait 'tapée' sur le clavier de l'ordinateur. Cette pseudo clé USB simule la frappe de 44 caractères sur votre clavier. cette séquence est chaque fois différente mais présente toujours la structure suivante :

* secret ID :(6 octets)
* session counter: (2 octets)
* horodatage: (3 oct)
* compteur de session :(1 oct)
* valeur aleatoire :(2 oct)
* Controle CRC : (2 oct)


Le tout encodé en AES 128 bits puis protegé par l'encodage MODHEX

La firme propose un service de validation en ligne des OTP. Mais il est possible de monter soit même un service de validation interne à son entreprise.

Le cout de cette clé : de 10 $ à 25 $ en fonction du volume.

La liste des services ou logiciels compatibles s'allonge tous les jours :

* Login sous Windows
* PAM
* SSH
* openID
* VPN
* Rails
* openSSO
* APACHE
* et ... Mandriva.



Déroulement d'une connexion:

* L'utilisateur glisse sa clé dans un port USB
* Le formulaire web lui demande son OTP.
* L'utilisateur presse le bouton de la clé ou 2 fois la touche verrouillage du pavé numérique.
* La clé inscrit les 44 caractères dans le champs du formulaire.
* Apres vérification auprès du fournisseur d'identité un autre formulaire est envoyé demandant le nom d'utilisateur et le mot de passe.
* L'utilisateur complète le formulaire et est accepté par le service.

REMARQUE IMPORTANTE: il serait possible de mettre les 3 secrets dans la même page, mais cela serait moins sécurisé car un pirate pourrait capturer les 3 secrets dans un seul échange (revoir ou relire le 'seigneur des anneaux' pour les questions de secret partagé) .

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

SSO CAS exemple de servlet

Utiliser la librairie client CAS de Yale dans le cadre d'un servlet est très simple :
Une fois récupéré le ticket , le servlet doit le faire valider par le serveur CAS de cette facon :


/* contact CAS and validate */
sv.validate();

/* if we want to look at the raw response, we can use getResponse() */
xmlResponse = sv.getResponse();

/* read the response */

// Yes, this method is misspelled in this way
// in the ServiceTicketValidator implementation.
// Sorry.
if(sv.isAuthenticationSuccesful()) {
user = sv.getUser();
} else {
errorCode = sv.getErrorCode();
errorMessage = sv.getErrorMessage();
/* handle the error */
}

Il reste un problème : Le client CAS standard n'accepte de valider un ticket qu'en utilisant le protocole HTTPS. Or pour les tests, il est parfois plus facile d'utiliser HTTP pour faciliter la capture des trames réseaux.

J'ai donc adapté le client CAS de cette façon :

Attention le code semble complexe mais il est une série de copier/coller

 import javax.servlet.*;

 import javax.servlet.http.*;

 import java.io.*;

 import edu.yale.its.tp.cas.client.*;

 import org.xml.sax.*;

 import java.net.URL;

 import java.net.URLConnection;

 import java.util.regex.*;

   

 public class MyServlet extends HttpServlet {

 

  public void init() {

  }

  public void doGet(HttpServletRequest req, HttpServletResponse res)

    throws ServletException, IOException {

       

        String CASLogin = "http://cas.demo.net/cas/login" ;

        String CASValidate = "http://cas.demo.net/cas/serviceValidate/" ;

            String UrlMonService = "http://serviceprovider.demo.net:8080/servlets- examples/servlet/myservlet";



 String ticket = req.getParameter( "ticket");

 if (ticket == null )

 {     

     res.sendRedirect( CASLogin + "?service=" +UrlMonService);

 }  else {

    res.setContentType("text/html");

    PrintWriter out = res.getWriter();

   



    edu.yale.its.tp.cas.client.ServiceTicketValidator st = new  edu.yale.its.tp.cas.client.ServiceTicketValidator();

    st.setCasValidateUrl(CASValidate);

    st.setServiceTicket( ticket );

    st.setService( UrlMonService );

    StringBuffer sb = new StringBuffer();

    sb.append(CASValidate);

    if (CASValidate.indexOf('?') == -1)

        sb.append('?');

         else

            sb.append('&');

    sb.append("service=" + UrlMonService + "&ticket=" + ticket);

    String url = sb.toString();

    BufferedReader r = null;

        String response="" ;



    try {

            URL u = new URL(url);

            URLConnection uc = u.openConnection();

            uc.setRequestProperty("Connection", "close");

            r = new BufferedReader(new InputStreamReader(uc.getInputStream()));

            String line;

            StringBuffer buf = new StringBuffer();

            while ((line = r.readLine()) != null)

                buf.append(line + "\n");

            response = buf.toString(); 

          } finally {

            try {

                    if (r != null)

                    r.close();

                 } catch (IOException ex) {

                // ignore

                 }



     

          }

      Integer result =0;

      String user="";

    /* reponse negative */

       if   (response.indexOf("authenticationFailure") >= 0 )

        {

           result =0  ;

        }  else

        {

           result =1  ;

           Pattern p = Pattern.compile("(.+)");

           Matcher m = p.matcher(response);

        if (m.find()) {

                // recup du user

                 user= m.group(1) ;

                }

        }

 

        out.println("");

    out.println("");

    out.println("");

    out.println("Ma première servlet  v5  CAS Client ");

    if (result == 1 )

        {

         out.println("connexion reussie pour l\'utilisateur:" + user );

         out.println("Avec le ticket " + ticket);       

           }  else {  

       out.println("ERREUR  de connexion" );

       out.println("ticket " + ticket); 

    }

    out.println("");

    out.println("");

    out.close();    

     }

  }











 }

   

Good hacking

Google face aux architectes astronautes

On a assisté avec la sortie de google Chrome à un gros buzz pour pas grand chose .

Google n'a jamais caché son désir de contrôler toute la chaine utilisateur <==> ressources web.
Pour goolge le réseau EST la machine, le réseau n'est pas une application. C'est dans cette optique que google lance un navigateur.
Ce navigateur est remarquable sur deux points :
L'exécution dans des fenêtres indépendantes des rendus des pages web. Cela laisse présager un environnement multitâche.
La possibilité de consulter ses documents en ligne et hors ligne pour ensuite les resynchroniser.

C'est sur ce dernier point que que Microsoft se sent le plus attaqué , car les prochains systèmes d'exploitation de la firme de Seattle mettront en l'accent sur cette fonctionnalité.
Et c'est là qu'intervient le gourou Joel Spolsky du site http://www.joelonsoftware.com . Ce blog est l'un des plus intéressant qui soit . Son auteur est un ancien 'superprogrammeur' de chez Microsoft et a une vision clairvoyante sur ce qui agite le microcosme du web.

Ce qui fait la force des gens de Google c'est qu'ils n'écoutent pas forcement les architectes astronautes. Un architecte astronaute c'est quelqu'un qui a force de s'élever dans l'abstraction finis par atteindre des couches ou l'oxygène est trop rare pour respirer. Ces architectes ne raisonnent qu'en terme de 'pattern' (modèle) . Si on veut se rendre d'un point à un autre , ces architectes vont pensez en 'pattrern' et vont construire un modèle en 10 couches ,alors que vous ne désirez que vous rendre d'un point à un autre. Tout ceci est illustré par l'antagonisme entre le modèle DOD Tcp/IP (4 couches) et le modèle ISO de l'OSI en 7 couches. Les quatre couches ont gagnées.

Pour le reste le nom 'chrome' fait directement référence à Firefox dont google est un gros contributeur financier.

Voici un exemple de modèle saml / sso de chez google :





Puis chez un concurrent :




Lequel est le plus clair ?

SOA , féderation d'identité et gouvernance

A la suite de mes lectures sur le SOA et des echanges riches sur ce thème , j'ai réalisé cette 'big-picture' où sont representé les differents processus de gestion et les composants relatifs àla gestion d'identité. Dans une architecture SOA cette fédération peut etre utilisée pour les personnes mais aussi pour les composants entres eux par le biais d'empreinte et de signature.