Bonjour, Un grand merci à Ernest pour cette contribution. Nous l'avons mis en œuvre chez nous (en y ajoutant une petite boucle pour tester l'émetteur et l'unité du certificat pour ajouter une sécurité supplémentaire par rapport à la vérification déjà faite par apache). Ça se révèle très pratique. Vivement son intégration dans la 0.71.
Cordialement, Oliver Dans sa grande sagesse, Julien Dombre a écrit, le 29.05.2007 00:21 : > 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 > -- Oliver Henriot, UMS MI2S, http://mi2s.imag.fr/ Moyens Informatiques et Multimédia Domaine universitaire BP53 / 38041 Grenoble cedex 9 / France tel.: +33 4 76 51 43 48 fax: +33 4 76 51 47 15 Trust in CNRS's certificates http://igc.services.cnrs.fr/Doc/General/trust.html _______________________________________________ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
