diff options
Diffstat (limited to 'zarb-ml/mageia-sysadm/2010-November/000945.html')
| -rw-r--r-- | zarb-ml/mageia-sysadm/2010-November/000945.html | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/zarb-ml/mageia-sysadm/2010-November/000945.html b/zarb-ml/mageia-sysadm/2010-November/000945.html new file mode 100644 index 000000000..21bf115a6 --- /dev/null +++ b/zarb-ml/mageia-sysadm/2010-November/000945.html @@ -0,0 +1,180 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20%5BLONG%5D%20sympa%20%28%20and%20web%20apps%20%29%20ldap%0A%09authentication&In-Reply-To=%3CAANLkTinooTSNqnf5hPU3AHTAZv7u7dnOzAoHLMuNFg9C%40mail.gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="000940.html"> + <LINK REL="Next" HREF="000947.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication</H1> + <B>Romain d'Alverny</B> + <A HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20%5BLONG%5D%20sympa%20%28%20and%20web%20apps%20%29%20ldap%0A%09authentication&In-Reply-To=%3CAANLkTinooTSNqnf5hPU3AHTAZv7u7dnOzAoHLMuNFg9C%40mail.gmail.com%3E" + TITLE="[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication">rdalverny at gmail.com + </A><BR> + <I>Thu Nov 25 20:16:20 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="000940.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000947.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#945">[ date ]</a> + <a href="thread.html#945">[ thread ]</a> + <a href="subject.html#945">[ subject ]</a> + <a href="author.html#945">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Thu, Nov 25, 2010 at 18:54, Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-sysadm">misc at zarb.org</A>> wrote: +><i> Le jeudi 25 novembre 2010 à 10:50 +0100, Buchan Milne a écrit : +</I>><i> My point is that we should be consistent. Ie, if we start using +</I>><i> sometimes a username, sometimes a email ( and well, I must say "one of +</I>><i> the numerous email people have", because I am pretty sure that I am not +</I>><i> the only one to have more than 1 email ), this will be annoying. +</I> +When we set up my.mandriva.com back in 2005, using the email address +instead of login to authenticate has been a big improvement: way less +contacts from people saying "I forgot my username" or trying to +re-register with an already used email address and a different login +(and then failing to do so). + +In this case, it may be that the cognitive effort to remember an email +address one already uses regularly is easier than the one to remember +a username that one may use only to authenticate (actually, that was +the hypothesis back at the time). + +><i> We cannot use email everywhere, since some services do not support it +</I>><i> ( svn+ssh will not accept it, no @ in username IIRC, neither would the +</I>><i> current buildsystem ). And doing translation will be source of +</I>><i> confusion. +</I> +Yes, that's a drawback, but an acceptable one I think: + * only for people that will use code repositories and buildsystem; that is, + * you are not forced to allow user identification against a single +id; what you need is just something you know identifies the user for +sure (if the email unicity and ownership are both proven, that's a +pretty good hint). So you can both authenticate against email/pass and +login/pass (and even have several email/login for that, if they are +checked against first). + +><i> Morever, using email as a login would mean that it would appear at a lot +</I>><i> of place on the web, and that's the sort of leak that should be avoided +</I>><i> at least for spam prevention reason ( and because some people will +</I>><i> complain, and complained in the past for example on bugzilla ). +</I> +You're mixing the "login token" and the "public name" issues. +Actually, you can use any type of id that is unique to a user to +identify (so both username and email would be valid). And you can use +a "public name" field to publish the user identity through all public +media. + +In Mandriva online service, you use your email to authenticate, and it +does not show up anywhere (through the network of apps using +my.mandriva, that is). Only a public name handle is printed out. + +><i> Well, the fact is managing a ldap of 400 accounts is not the same scale +</I>><i> to me than one of 60 000 to 1 000 000 entries. ( if I take the range of +</I>><i> users of Mandriva forum to the range of Ubuntu's one ). [...] +</I> +I would worry about that scale when it will become to be an issue. Because: + * it won't grow so big in one single night. + * when it will, there will likely be resources to cope with it +(traffic does not just come alone). + * I expect LDAP to scale much better than a typical MySQL db + PHP +web service setup. + +><i> [...] letting people freely edit the attribute they +</I>><i> use for login is IMHO a risky operation given the wide range of +</I>><i> application that we will have. +</I> +Why is it risky? + +><i> Editing by admin should be ok. +</I> +Editing by user is ok too. Provided you check for unicity of the id +through the whole system and, eventually, lock some past used ids. + +><i> Several people asked in the past to use the ml to nntp gateway of gmane. +</I>><i> ( and to some extend some kind of forum to ml gateway ) +</I>><i> +</I>><i> So this require the service to subscribe to our ml. And in turn, this +</I>><i> mean opening a account for the service ( while before, it was able to +</I>><i> fully subscribe automatically at least for gmane ). So maybe there is +</I>><i> other popular services like there that could requires this. +</I>><i> +</I>><i> We can also use the option "we do not care", or "it will just be a +</I>><i> little bit difficult" or "we will do it by hand", of course. +</I> +Would it mean to manually do something: once per such a "user", or +once per subscription (gmane subscribing to several ml for instance)? + +><i> - we use ldap for everything related to auth, and only ldap. Maybe 1 +</I>><i> local admin password for some rare applications that requires it . +</I>><i> +</I>><i> - we use username as login, and do not let user change it. +</I> +Two solutions here then: + - either the user cannot change her username, and then have a "public +name" field that is used everywhere the public handle of the user is +to be used (or leave this option to the user); and this "public name" +should be editable; rationale: I want the option to appear as "Romain +d'Alverny" and not as "rda" or "romain" in all web apps; + - either the user can change her username, and some other unique, +static id (not being usually human-readable) must exist and be used by +all apps authenticating against the directory, to manage user's local +belongings. + +><i> ( as changing login would likely requires modification on the local +</I>><i> account information that every application will likely create, and +</I>><i> that's sound like a bad idea from a security ( ie main ldap access to +</I>><i> every other web app database, even if a pull system could solve this +</I>><i> issue ), +</I> +I would more design some event system notifying all trusted/registered +apps that a given user has updated info, and let the app manage what +to do (the basic event being, "this user just logged in your +application, see her account, diff it against your local copy and see +what you need to change on your side"). + +><i> maintainability ( hook/script to modify the data on every +</I>><i> impacted web applications, dependant on internal structure of the +</I>><i> application +</I> +This is likely to happen anyway to update local copies of user data +coming from the directory, usually on user login into these apps. + +><i> - we filter on team when needed +</I> + +Romain +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000940.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000947.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#945">[ date ]</a> + <a href="thread.html#945">[ thread ]</a> + <a href="subject.html#945">[ subject ]</a> + <a href="author.html#945">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-sysadm">More information about the Mageia-sysadm +mailing list</a><br> +</body></html> |