[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication

Thu Nov 25 20:16:20 CET 2010

On Thu, Nov 25, 2010 at 18:54, Michael Scherer <misc at zarb.org> wrote:
+> Le jeudi 25 novembre 2010 à 10:50 +0100, Buchan Milne a écrit :
+> My point is that we should be consistent. Ie, if we start using
+> sometimes a username, sometimes a email ( and well, I must say "one of
+> the numerous email people have", because I am pretty sure that I am not
+> the only one to have more than 1 email ), this will be annoying.
+
+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).
+
+> We cannot use email everywhere, since some services do not support it
+> ( svn+ssh will not accept it, no @ in username IIRC, neither would the
+> current buildsystem ). And doing translation will be source of
+> confusion.
+
+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).
+
+> Morever, using email as a login would mean that it would appear at a lot
+> of place on the web, and that's the sort of leak that should be avoided
+> at least for spam prevention reason ( and because some people will
+> complain, and complained in the past for example on bugzilla ).
+
+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.
+
+> Well, the fact is managing a ldap of 400 accounts is not the same scale
+> to me than one of 60 000 to 1 000 000 entries. ( if I take the range of
+> users of Mandriva forum to the range of Ubuntu's one ). [...]
+
+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.
+
+> [...] letting people freely edit the attribute they
+> use for login is IMHO a risky operation given the wide range of
+> application that we will have.
+
+Why is it risky?
+
+> Editing by admin should be ok.
+
+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.
+
+> Several people asked in the past to use the ml to nntp gateway of gmane.
+> ( and to some extend some kind of forum to ml gateway )
+>
+> So this require the service to subscribe to our ml. And in turn, this
+> mean opening a account for the service ( while before, it was able to
+> fully subscribe automatically at least for gmane ). So maybe there is
+> other popular services like there that could requires this.
+>
+> We can also use the option "we do not care", or "it will just be a
+> little bit difficult" or "we will do it by hand", of course.
+
+Would it mean to manually do something: once per such a "user", or
+once per subscription (gmane subscribing to several ml for instance)?
+
+> - we use ldap for everything related to auth, and only ldap. Maybe 1
+> local admin password for some rare applications that requires it .
+>
+> - we use username as login, and do not let user change it.
+
+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.
+
+> ( as changing login would likely requires modification on the local
+> account information that every application will likely create, and
+> that's sound like a bad idea from a security ( ie main ldap access to
+> every other web app database, even if a pull system could solve this
+> issue ),
+
+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").
+
+> maintainability ( hook/script to modify the data on every
+> impacted web applications, dependant on internal structure of the
+> application
+
+This is likely to happen anyway to update local copies of user data
+coming from the directory, usually on user login into these apps.
+
+> - we filter on team when needed
+
+
+Romain
+