Bonjour, merci de vos informations. La mise en oeuvre dans GLPI de ce type d'authentification va nécessité pas mal d'analyse et de tests. Nous ne pourrons donc pas matériellement l'intégrer dans la 0.7 qui est en court de finalisation.
Par contre j'ai ouvert un ticket pour l'intégration dans la 0.71. https://dev.indepnet.net:8080/glpi/ticket/903 merci encore pour votre contribution. Nous vous tiendrons au courant de l'avancée du travail pour que vous puissiez tester une fois en place. Cordialement, Julien Dombre Ernest CHIARELLO a écrit : > merci pour votre réponse, > > Julien Dombre a écrit : >> Bonjour, >> >> merci de l'intérêt que vous portez au projet GLPI. > je ne suis pas le seul ! ;-) . GLPI est un super produit. j'ai > participé récemment > à un concours de promotion interne au CNRS, et j'ai constaté que la > plupart des > administrateurs systèmes et réseaux du monde de la recherche utilisent > GLPI. > merci à vous ! >> >> J'ai regardé attentivement votre proposition. N'ayant pas vraiment de >> moyen pour tester cela rapidement dans l'immédiat, je me permet de >> vous demander un peu plus d'informations dès à présent. >> >> Cela veux dire que pour vous connecter à GLPI avec un certificat vous >> devez appeler directement la page login.php ? > non, je continue à m'authentifier avec index.php, mais je tape un > login et un mot de passe uniquement > si je souhaite utiliser un login/passwd pour m'authentifier avec un > login qui ne correspond pas à mon > certificat. > par exemple pour etre root et non le user correspondant à mon certificat. > sinon, je clique sur valider, sans login ni passwd, si je souhaite me > connecter avec mon certificat. > mais vous avez raison pour les utilisateurs : pour ne pas les > perturber, il faudrait les envoyer directement > sur login.php dès lors qu'ils ne peuvent se connecter qu'avec leur > certificat. >> Ne peux t'on pas imaginer un système comme pour CAS ou la redirection >> st faite par defaut avec une URL du type >> index.php?noCERT=1 pour utiliser un login normal ? > oui, je pense... >> Ou faut-il faire le check de la présence du certificat, de sa >> validité sur la page index.php ? >> > même si on a un certificat, on doit pouvoir se connecter en root pour > des raisons d'administration. > on peut aussi vouloir utiliser un login d'un utilisateur pour faire > "comme lui" quand on fait du > support téléphonique sur GLPI... >> D'après le code fournit vous utiliser l'attribut emailAddress du >> certificat pour définir le login. >> Cela ne semble pas standard. Il faudrait donc prévoir une >> configurabilité de l'attribut utilisé non ? >> > c'est comme on veut. > mais les homonymes existent, alors que les adresses identiques > n'existent pas. > exemple : je connais deux Francoise Martin. si je calcule le login sur > le nom/prenom, > je ne m'en sors pas. > en revanche, si je prends leurs adresses, alors j'ai bien deux > identifiants différents. > et c'est un exemple de la vraie vie. >> Comment valider que le certificat utilisateur est correct ? Cela se >> fait tout seul ? > c'est le boulot de apache, dans 41_mod_ssl.default-vhost.conf en général. > > # Certificate Authority (CA): > # Set the CA certificate verification path where to find CA > # certificates for client authentication or alternatively one > # huge file containing all of them (file must be PEM encoded) > # Note: Inside SSLCACertificatePath you need hash symlinks > # to point to the certificate files. Use the provided > # Makefile to update the hash symlinks after changes. > SSLCACertificateFile conf/ssl/ca-bundle.crt > > ce fichier contient la liste des autorités de certification en > lesquelles je fais > confiance : > > # grep Subject ../ssl/ca-bundle.crt > Subject: C=FR, O=CNRS, CN=CNRS > Subject Public Key Info: > X509v3 Subject Key Identifier: > Subject: C=FR, O=CNRS, CN=CNRS-Plus > Subject Public Key Info: > X509v3 Subject Key Identifier: > Subject: C=FR, O=CNRS, CN=CNRS-Standard > Subject Public Key Info: > X509v3 Subject Key Identifier: > Subject: C=FR, O=CRU, CN=ac-racine/[EMAIL PROTECTED] > Subject Public Key Info: > X509v3 Subject Key Identifier: > Subject: C=FR, O=CRU, > CN=ac-utilisateur/[EMAIL PROTECTED] > Subject Public Key Info: > X509v3 Subject Key Identifier: > > sans être expert des IGC (infrastructures à gestion de clés), on > reconnait : > les autorités CNRS, CNRS-Plus, CNRS-Standard pour le CNRS ; > les autorites ac-racine et ac-utilisateur pour le CRU des universités. > > quand un utilisateur arrive avec un certificat, je sais exactement qui > il est, car je fais > confiance aux autorités qui ont délivré ce certificat. > de même qu'on fait confiance à une mairie quand on lit une carte > d'identité. > > ensuite, c'est à l'application de savoir ce qu'elle fait de ce > certificat, car ce n'est > pas parce qu'un utilisateur est authentifié qu'il a le droit de se > connecter ! > > dans mon cas, je décide qu'un possesseur de certificat est un vrai > utilisateur, digne > de se connecter sur mon GLPI. > pour être rigoureux, je pourrais vérifier qu'il détient un certificat > obtenu via ma > délégation régionale (dr7) et non la délégation voisine (dr11). > > mais GLPI n'est pas ouvert à l'internet dans mon cas, c'est une > application locale cachée > derrière un pare-feu. > > si un utilisateur de la dr11 venait sur mon site, s'il transportait > son certificat sur une > de mes machines, alors il aurait de droit de se connecter sur GLPI, et > son compte > serait créé à la volée. > > je n'ai pas analysé le code de Egroupware car il est assez complexe. > mais il a un défaut : > il laisse un utilisateur se connecter avec son certificat alors qu'il > a fourni un login valide. > résultat : l'utilisateur peut passer root s'il choisit l'identifiant > root... il faut que je leur écrive... > > > > en espérant avoir répondu à vos questions, > > Ernest. > >> >> Cordialement, >> >> Julien Dombre >> >> >> Ernest Chiarello a écrit : >>> bonjour, >>> >>> dans notre système d'information, nous utilisons des certificats >>> X509 pour l'authentification >>> des utilisateurs. >>> mais GLPI ne prévoit pas ce type de fonctionnalité... aussi je me >>> suis permis de modifier >>> login.php pour intégrer l'authentification par certificat. >>> >>> qu'en pensez-vous ? >>> >>> je vous joins la version de ligin.php que je propose. >>> >>> son fonctionnement : >>> si l'utilisateur fournit un login et un mot de passe, il sera >>> identifié par ce couple si le >>> compte est créé dans la base glpi. >>> si l'utilisateur ne fournit rien, on regarde s'il a un certificat, >>> et si oui, on l'authentifie >>> avec ce certificat. si le compte n'existe pas, on le crée à la volée >>> en imposant un >>> mot de passe. >>> si on n'est pas dans ces cas, on contacte les serveurs pop, ldap ou >>> active directory. >>> >>> je précise aussi qu'une partie du code est extraite de EgroupWare >>> (l'extraction des >>> infos du certificat). >>> >>> merci pour votre écoute, >>> >>> Ernest. >>> -- >>> Ernest CHIARELLO - [EMAIL PROTECTED] >>> >>> Je signe mes courriers électroniques avec un certificat CNRS. >>> http://igc.services.cnrs.fr/Doc/General/trust.html >>> _______________________________________________ >>> Glpi-dev mailing list >>> Glpi-dev@gna.org >>> https://mail.gna.org/listinfo/glpi-dev > > _______________________________________________ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
