SSO

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?)

Pages dédiées

• LibertyAlliance

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.

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 (ldapsearch...).

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.

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 :(

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.

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

Autres

• Shibboleth: rapport avec Internet2?, serveur d'identité en Java :(
• OpenID (décentralisé, identifiants unique mais pas vraiment SSO)
• A-Select

Liens

• Single Sign-On sur Wikipedia