merci pour votre réponse, Julien Dombre a écrit :
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 desBonjour,merci de l'intérêt que vous portez au projet GLPI.
administrateurs systèmes et réseaux du monde de la recherche utilisent GLPI. merci à vous !
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 à monJ'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 ?
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 typeindex.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.crtce 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'authentificationdes utilisateurs.mais GLPI ne prévoit pas ce type de fonctionnalité... aussi je me suis permis de modifierlogin.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 lecompte 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 unmot 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 desinfos 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
-- Ernest CHIARELL0, [EMAIL PROTECTED] RSI - CNRS, Délégation régionale Rhône-Auvergne tel : 04 72 44 56 77 - Fax : 04 72 44 56 73 2 avenue Albert Einstein, 69609 Villeurbanne Cedex -- je signe mes courriers électroniques avec un certificat CNRS. Téléchargez le certificat de l'IGC http://igc.services.cnrs.fr/CNRS-Standard/?lang=fr&cmd=search_CA_certificate&body=view_ca.html
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
