SSO

Single Sign-On - authentification unique pour accéder à plusieurs services différents.

Critères

• Architecture:
  • Identifiant unique vs. identification unique
  • Technos/langages libres
• Au niveau fournisseur d'identité:
  • Méthode d'authentification: intégrée, lien LDAP/RADIUS/..., arbitraire (appel exécutable externe)
• Au niveau service:
  • Mise en place: transparent/proxy, variables d'environnement Apache, code spécifique
  • Identifiant: anonymisé ou réel (ex: comment récupérer les groupes de l'utilisateur?)
  • Authentification facultative (service semi-public) ou obligatoire
  • Problème du webmail: faire passer l'authentification au serveur IMAP
  • Portabilité

Liberty Alliance

Fonctionnement par redirections HTTP (entre autres); il existe également des proxy (Larpe). Pas d'accès à l'identifiant réel de l'utilisateur (confidentialité). Cela en fait un outil intéressant pour des services publics sans rapport entre eux.

• Page dédiée: LibertyAlliance

CoSign - Collaborative Single Sign-On

http://www.umich.edu/~umweb/software/cosign/

Fonctionne comme filtre Apache (style scalp de LibertyAlliance), puis définit la variable d'environnement REMOTE_USER. Peut apparemment s'interfacer avec Kerberos.

Il est possible de lier le weblogin à un service d'authentification externe via un appel à un exécutable externe (Net::LDAP...).

• Page dédiée: CoSign

CAS - Central Authentication Service

http://www.ja-sig.org/products/cas/

Ressemble à LibertyAlliance, mais permet de récupérer le nom de l'utilisateur. Perte de confidentialité, mais utile pour des services différents détenus par une même entité (ex: plusieurs applications d'un extranet) - single-institution SSO par opposition à cross-domain federated authentication.

Serveur CAS en Java.

Page dédié: CAS

Vulture

http://vulture.open-source.fr/wiki/

Fonctionnement par reverse proxy. Configuration via une interface web.

Fonctionne en lançant des serveurs Apache+mod_proxy, un pour l'interface web et un par domaine SSO, chacun avec son fichier de configuration dans /var/www/vulture/n.conf.

Des problèmes de cache bizarre avec Firefox (pas de prise en compte des changements; deux URLs différentes pointant sur un seul service à la place de deux différents...). Authentification sur une session seulement, il faut se réauthentifier à chaque fois que l'on ferme son navigateur. Pas de single logout (ni depuis l'application, ni depuis vulture), mais comme dit plus haut il suffit de fermer son navigateur.

LemonLDAP

http://wiki.lemonldap.objectweb.org/xwiki/bin/view/Main/WebHome

Module Apache+mod_perl, fonctionnement par reverse proxy; gère une couche d'autorisation en associant un utilisateur à un sous-ensemble des services disponibles. Nécessite apparemment d'ajouter un schéma au serveur LDAP pour gérer les services auxquels chaque utilisateur a accès.

Auth MemCookie

http://authmemcookie.sourceforge.net/

Module Apache; permet d'authentifier automatiquement en fonction d'un cookie partagé sur un domaine (*.domaine.tld). La session est stockée dans un memcached, donc partageable entre plusieurs ordinateurs. Intérêt: pas de serveur d'identités à mettre en place, un simple formulaire de login suffit.

La sécurité est cependant plus faible, car le seul contrôle d'accès de memcached est l'adresse IP. Dans le cas de plusieurs machines de confiance, prévoyez un VPN. Dans le cas d'une machine partagée / mutualisée, oubliez (n'importe quel autre utilisateur peut modifier le cache, et donc l'utilisateur associé à un cookie - par admin notamment).

Il manque la possibilité de définir le domaine du cookie (pour le partager entre plusieurs sous-domaines); le formulaire de login doit donc être sur le domaine parent.

Il est obligatoire de s'authentifier; il n'est pas possible d'accéder au service en mode anonyme, puis de passer en mode authentifié, par exemple.

Apache::AuthCookie

Similaire à authmemcookie, mais peut stocker la session ailleurs que dans memcached (ex: Apache::AuthCookieDBI), ce qui permet d'envisager une meilleure sécurité.

Le module (et ses classes dérivées) fonctionne sous Apache1, le module Apache2 est en version beta et ne dispose pas encore de classes dérivées.

Autres

• Shibboleth: rapport avec Internet2?, serveur d'identité en Java :(
• OpenID (décentralisé, identifiants unique mais pas vraiment SSO)
• A-Select: à creuser; Java nécessaire au moins pour le serveur; pas d'accès aux sources des versions > 1.4.0 (?)

Liens

• Single Sign-On sur Wikipedia