Journal : clé d'identification d'un utilisateur?
Posté par . Takhi () le 03 septembre 2007
Bonjour,
peut etre des gens parmi vous ont deja solutionné ce genre de probleme...
Je souhaiterais creer un referentiel d'identité dans un annuaire Ldap ( plus exactement améliorer celui qui existe à l'heure actuelle.)
Pour cela il faut donc que je determine l'attribut Rdn qui va etre utilisé.
( sachant que pour le moemnt c'est le UID .. pas top )
Et qui si possible n'evoluerai pas dans le temps...
La solution du login de l'utilisateur me semble problématique:
- certains utilisateurs ont plusieurs logins ( suivant les environnements )
- certains n'utilisent que des logins génériques ( utilisateurs temporaires, interimaires, stagiaires.. )
La solution du nom+prénom me pose également probleme, car le nom peut evoluer , et il y a risque d'homonymie ( on risque d'avoir collision sur les Pierre Dupont )
La solution du numéro d'employé pourrait etre intéressante, sauf que les prestataires et interimaires n'en ont pas..(enfin chez nous en tout cas)
Le numéro de sécu on peut oublier d'emblée
- on n'en a pas le droit ( donc deja...)
- je ne crois pas que l'on aie de normes internationales dessus
Bref je serais preneur d'une bonne idée , qui soit CNIL- compliant :-
Merci plein par avance.
peut etre des gens parmi vous ont deja solutionné ce genre de probleme...
Je souhaiterais creer un referentiel d'identité dans un annuaire Ldap ( plus exactement améliorer celui qui existe à l'heure actuelle.)
Pour cela il faut donc que je determine l'attribut Rdn qui va etre utilisé.
( sachant que pour le moemnt c'est le UID .. pas top )
Et qui si possible n'evoluerai pas dans le temps...
La solution du login de l'utilisateur me semble problématique:
- certains utilisateurs ont plusieurs logins ( suivant les environnements )
- certains n'utilisent que des logins génériques ( utilisateurs temporaires, interimaires, stagiaires.. )
La solution du nom+prénom me pose également probleme, car le nom peut evoluer , et il y a risque d'homonymie ( on risque d'avoir collision sur les Pierre Dupont )
La solution du numéro d'employé pourrait etre intéressante, sauf que les prestataires et interimaires n'en ont pas..(enfin chez nous en tout cas)
Le numéro de sécu on peut oublier d'emblée
- on n'en a pas le droit ( donc deja...)
- je ne crois pas que l'on aie de normes internationales dessus
Bref je serais preneur d'une bonne idée , qui soit CNIL- compliant :-
Merci plein par avance.
> Lire le journal (8 commentaires, moyenne: 2,9).
Vous avez demandé le commentaire #863419.
Run by 
Cette page a été générée par Templeet en 0.042s (dont 0.0041 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Identifiant unique et annuaire
Ton exposition du problème reste un peu incomplète :
- Quelle est la structure de ton annuaire ? À quoi sert-il ? S'il y a de nombreuses branches (une par service, par exemple), les problèmes d'homonymie sont moins critiques.
- Qu'appelles-tu le UID ? Le UUID attribué automatiquement par l'annuaire, ou un UID attribué par une application externe ou l'entreprise (i.e. techniquement indépendant de l'annuaire) ? Dans le second cas, je trouve que c'est un très bon choix car il est +/- anonyme et stable.
- N'est-il pas possible d'utiliser la partie gauche de l'adresse mail ?
- N'est-il pas possible d'affecter un numéro d'employé fictif aux prestataires, avec un préfixe comme suggéré par nicO ?
- Moins important, peut-être : y a-t-il des applications, utilisatrices de l'annuaire, qui imposent des contraintes sur le format de ce RDN?
Dans tous les cas :
- y a-t-il une raison valable d'avoir un RDN « lisible », à part pour le confort de l'exploitant ou de l'administrateur ?
- qui est le « propriétaire » de l'annuaire : le service informatique/la DSI, les ressources humaines, un autre service ? Son responsable a peut-être une idée sur la question ou, plus probablement, des contraintes à imposer.
- La stabilité du RDN est effectivement importante, car c'est elle qui facilitera la prise en compte des mobilités dans l'entreprise, les changements de fonctions et tous les mouvements de ce type.
Il y a un tas de ressources en ligne sur les annuaires LDAP, ainsi que des bouquins. Si tu mets la main sur l'un d'eux, il y aura forcément un chapitre sur cette question.
Enfin, as-tu pensé à consulté les archives ou les abonnés de la liste LDAP du CRU ? Tu trouveras cela ici : http://www.cru.fr/ldap/ C'est un peu orienté « éducation », mais les participants sont réactifs, serviables et d'un bon niveau.
BB
[^]Re: Identifiant unique et annuaire
L'annuaire est essentiellement un aggrégat des différents "referentiels" d'habilitations dont on dispose dans la maison, c'est un poil hétérogene, et l'idée etait plutot de rendre l'annuaire 'Maitre' de ces différentes bases de données si cela etait possible. Il sert surtout à fournir aux applicatifs une base un peu standardisée afin de ne pas avoir à redéfinir une nouvelle infrastructure d'habilitations ( et ainsi économiser enormément, a la fois sur la mise en place et sur le maintient )
Au niveau de la structure : j'envisages essentiellement une structure arborescente pour les services, mais une structure "a plat" pour les utilisateurs en jouant sur les memberOf ou des roleOccupant pour y affecter les utilisateurs afin de minimiser le nombre de créations/suppressions d'entrées. ( et surtout permet de limiter les problemes de multiples casquettes ... )
-Quand je parle d'UID c'est le login Windows , ce qui pose un probleme de doublons ( on a des users windows génériques utilisés par plusieurs personnes et des personnes ayant plusieurs login windows... faut pas chercher ya de l'historique derriere :/ )
-On ne dispose -encore- pas de veritable regle de generation des adresses email ( entre les internes, les prestas ... ) et encore une fois , il y a un existant...
- le propriétaire de l'annuaire est la DSI, vu qu'il ne sert pour le moment que de referentiel d'habilitations pour nos applicatifs
- niveau applicatif les problemes possibles sont tres localisés, peu d'applications exploitent les données de cet annuaire et la récupération des données
est centralisée par un webservice ( comme ca en cas de changement de structure on limite l'impact)
Je vous remercie en tout cas pour toutes ces réponses et ces pistes.