Heritage d'Authentification

Bonjour,

Je souhaiterai mettre en place un portail d'authentification LDAP
unique.
Derriere un accés à divers site (divers hebergeurs) possédant leur
authentifications propre (pour le moment).
Un peu comme le fait google pour c'est différent web-services
(l'authentification est conserver que l'on passe de Gmail à Docs &
Spreadsheets > Calendar > Notebook > Analytics > Sitemaps ...ect...)

Quels sont les pré-requis et la méthode la plus adéquate..

Si tu as remarqué, le domaine de Google Mail est mail.google.com,
celui du moteur de recherche est www.google.com, celui du calendrier
est www.google.com/calendar, celui de la suite office est
docs.google.com, Google Groups est groups.google.com (ou
groops-beta.google.com... bref, Google utilise un système de Cookies
liés au domaine google.com pour conserver les configuration
d'authentification et de préférences.

Tu dois faire de même sur ton site ; tu ne peux pas avec une portion
de ton site sur domain1.com et l'autre sur domain2.com par example, en
utilisant cette méthode (comme Google)

Une option intéressante est d'utiliser le module APC pour PHP (source
disponible ici http://pecl.php.net/package/APC/download/ et en dll ici
http://ca3.php.net/get/pecl-5.2.0-Win32.zip/from/a/mirror) qui permet
de conserver de l'information en cache, disponible entre les
différentes sessions utilisateurs (à utiliser avec modération !!!!).
Alors, domain1.com et domain2.com pourraient contacter domain-base.com
pour avoir les information de login (avec l'id de session) et tu serais
en affaire.

En alternative à APC, tu peux toujours écrire ton propre petit script
PHP qui sauvegarde des informations de session dans un fichiers
indépendant... mais c'est vraiseemblablement réinventer la roue !

Évidemment, Google a opté pour la permière solution (Cookies) parce
qu'elle est la plus sécuritaire et la moins difficile à gérer.

En ce qui concerne LDAP, j'ai trouvé un petit script intéressant sur
www.phpclasses.org (que j'ai beaucoup modifié pour qu'il fonctionne
bien avec AD sous Windows 2003 serveur) et mes utilisateurs
s'authentifient avec ça -- et si LDAP est en panne, les dernières
informations d'authentification sont stockées dans une table mySQL, en
fail safe -- .


Bonne chance !

Yanick

Merçi Yanick,

je recherché du coté du Mécanisme d'authentification unique, et
j'ai trouvé des solution du type CAS. Il s'agit je pense d'une sorte
de serveur d'authentification.
Ce type d'authentification implique certainement le remaniement de
l'ensemble des méthodes d'authentification des applications...
L'idéal aurait été de pouvoir établir sur le serveur CAS une table
de correspondance, ou chaque compte contient toute les informations
pour établir une redirection authenfié sur les diverses
applications...

Merçi Yanick,

je recherché du coté du Mécanisme d'authentification unique, et
j'ai trouvé des solution du type CAS. Il s'agit je pense d'une sorte
de serveur d'authentification.
Ce type d'authentification implique certainement le remaniement de
l'ensemble des méthodes d'authentification des applications...
L'idéal aurait été de pouvoir établir sur le serveur CAS une table
de correspondance, ou chaque compte contient toute les informations
pour établir une redirection authenfié sur les diverses
applications...

Je ne suis peut-être pas un expert dans le domaine (je ne programme en
PHP que depuis un an tout au plus), mais les variables de session en
PHP sont peut-être, finalement, une bonne solution :

1. le script regarde si $_SESSION contient les informations de login
2. Si Non, elle appelle le service d'authentification du serveur avec
session_id() comme paramètre ; le service d'authentification retourne
un document XML contenant la réponse
3. Si la réponse est insatisfaisante, le script redirige l'utilisateur
vers un formulaire d'authentification (avec un champ caché contenant
le lien de redirection vers l.URL à l'étape 1) ; le formulaire se
trouvant directement sur le serveur du domaine d'authentification.

Bref, ce n'est qu'une idée, mais il me semble que si tous tes services
ne sont pas sur le même domaine, tu peux très rapidement courir vers
des "trous" de sécurité.... Il est beaucoup plus facile de gérer des
sites répartis sur des sous domaines différents (parce que tu peux
partager les cookies par exemple) que de répliquer l'information
plusierus fois sur différentes machines et de synchroniser le tout au
fur et à mesure.

Merçi Yanick,

je recherché du coté du Mécanisme d'authentification unique, et
j'ai trouvé des solution du type CAS. Il s'agit je pense d'une sorte
de serveur d'authentification.
Ce type d'authentification implique certainement le remaniement de
l'ensemble des méthodes d'authentification des applications...
L'idéal aurait été de pouvoir établir sur le serveur CAS une table
de correspondance, ou chaque compte contient toute les informations
pour établir une redirection authenfié sur les diverses
applications...

Bonjour,

CAS pour Central Authentication Server est un service centralisé
d'authentification. Il est utilisé dans des solutions de type ENT et
notamment dans un ENT libre qui s'appelle E-SUP.

Un CAS impose de modifier le mécanisme d'authentification en
remplaçant l'authentification propre de l'application par un appel au
server CAS. Cela peut se présenter sous la forme :

phpCAS::client(CAS_VERSION_2_0,'sso-cas.mydomain.com',443,'');
phpCAS::forceAuthentication();
$uid=phpCAS::getUser();

Le reste, c'est à dire la gestion des sessions des droits d'accès
pour un utilisateur donné, sera toujours géré au sein de
l'application.


Sitch