Différences entre versions de « SSO »
imported>SylvainBeucler m (→Critères) |
imported>SylvainBeucler m (→Critères) |
||
Ligne 2 : | Ligne 2 : | ||
* Architecture: | * Architecture: | ||
− | + | ** Identifiant unique vs. identification unique | |
− | + | ** Technos/langages libres | |
* Au niveau fournisseur d'identité: | * Au niveau fournisseur d'identité: | ||
− | + | ** Méthode d'authentification: intégrée, lien LDAP/RADIUS/..., arbitraire (appel exécutable externe) | |
* Au niveau service: | * 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 == | == Pages dédiées == |
Version du 27 avril 2007 à 13:34
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
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 :(
Autres
- Shibboleth: rapport avec Internet2?, serveur d'identité en Java :(
- OpenID (décentralisé, identifiants unique mais pas vraiment SSO)
- A-Select
- authmemcookie: 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.
Liens
- Single Sign-On sur Wikipedia