Différences entre versions de « SSO »
imported>SylvainBeucler m (→Critères) |
imported>SylvainBeucler m (→CAS - Central Authentication Service : page dédiée CAS) |
||
| (9 versions intermédiaires par 2 utilisateurs non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
| + | Single Sign-On - authentification unique pour accéder à plusieurs services différents. | ||
| + | |||
== Critères == | == Critères == | ||
| Ligne 10 : | Ligne 12 : | ||
** Identifiant: anonymisé ou réel (ex: comment récupérer les groupes de l'utilisateur?) | ** Identifiant: anonymisé ou réel (ex: comment récupérer les groupes de l'utilisateur?) | ||
** Authentification facultative (service semi-public) ou obligatoire | ** 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 <code>REMOTE_USER</code>. 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 == | == Vulture == | ||
| Ligne 24 : | Ligne 50 : | ||
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. | 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 == | == LemonLDAP == | ||
| Ligne 39 : | Ligne 57 : | ||
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. | 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 == | == Auth MemCookie == | ||
| Ligne 51 : | Ligne 62 : | ||
http://authmemcookie.sourceforge.net/ | 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. | + | 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). | 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). | ||
| Ligne 58 : | Ligne 69 : | ||
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. | 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 == | == Autres == | ||
| Ligne 63 : | Ligne 80 : | ||
* [http://shibboleth.internet2.edu/ Shibboleth]: rapport avec Internet2?, serveur d'identité en Java :( | * [http://shibboleth.internet2.edu/ Shibboleth]: rapport avec Internet2?, serveur d'identité en Java :( | ||
* [http://openid.net/ OpenID] (décentralisé, identifiants unique mais pas vraiment SSO) | * [http://openid.net/ OpenID] (décentralisé, identifiants unique mais pas vraiment SSO) | ||
| − | * [http://www.a-select.org/ A-Select] | + | * [http://www.a-select.org/ A-Select]: à creuser; Java nécessaire au moins pour le serveur; pas d'accès aux sources des versions > 1.4.0 (?) |
== Liens == | == Liens == | ||
* [http://en.wikipedia.org/wiki/Single_sign-on Single Sign-On] sur Wikipedia | * [http://en.wikipedia.org/wiki/Single_sign-on Single Sign-On] sur Wikipedia | ||
Version actuelle datée du 2 avril 2008 à 14:09
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