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

Wed Nov 24 20:29:04 CET 2010

Hi,
+
+thanks for the long description. Instead of replying point by point, I
+would like to suggest a more radical point of view, that actually
+determined the my.mandriva setup (that would not make a difference
+between "regular" users and "active" users from a auth/storage POV). I
+think it's worth it to discuss it as well.
+
+The rationale is to ease the user flow through the project, as a
+whole. 4 points below.
+
+#1. General rule: all users authenticate the same way against a single directory
+
+Exceptions come later.
+ * the same way: email/password
+ * a single directory: LDAP (no local app user account unless it is
+admin/setup specific or the application integration is really
+separate)
+ * exceptions: when the application integration/workflow commands it
+(buildsystem access with login? sympa?)
+ * exceptions may be handled locally (they ask for login/password) or
+through an API (instead of calling LDAP, they call a specific
+webservice passing email/password, which service replies the login and
+local app uses returned values).
+
+(apart from the LDAP bit that was replaced by a MySQL db + web
+services, all of this was implemented at Mandriva, although not to a
+fully satisfying point)
+
+In my view, apps that qualify for this generic rule  (ldap only +
+local fallback for admin):
+ * bugzilla
+ * forum
+ * wiki
+ * actually, any webapps you could think of, provided you can make a
+ldap query from it
+
+That qualify for the login exception:
+ * svn/git/etc. (not sure but I guess so)
+ * other?
+
+
+#2. Consequences
+
+That means that identity should authenticate with email preferably
+(but may allow using the login).
+
+That does not prevent that local app data is locally stored. That's
+how my.mandriva scheme was designed (and could have gone further).
+That does not prevent that local apps provide a way for the user to
+build a mashup of all data around (for a reporting/activity/social net
+app for instance).
+
+That means that any user using any part of the Mageia infrastructure
+has to get an account through identity.mageia.org. And that
+email/login must be tested for unicity.
+
+That also puts some constraints on how an app manages authentication
+and local user data:
+ * it must be able to authenticate from an outside source
+ * it must be able to manage primary email change (we used a
+"customer_id" at Mandriva, a 64 char id that allowed to change both
+email and login at will without losing user reference; would that
+match the uid?)
+ * it must be able to update, if needed, locally cached data that
+source from the central repository.
+
+To some extent, it could even have the ability to manage a central
+session server, but that may be left for a later time (and can
+actually be managed almost separately once the central auth is done).
+
+(we may use OAuth and OpenID auth at a later time for web apps. That
+shouldn't have an impact on the above (and below) authentication
+scheme anyway)
+
+So what about apps that do not support this scheme? We patch them so
+they do (and we do it the clean way). Puts more constraints on the
+dev/admin side, for sure; but again, the rationale is to provide a
+consistent interface to the user with easiest to remember items (email
+then, instead of login). And that forces us to find a consistent
+protocol that is already (or should be) implemented in our apps.
+
+
+#3. Sympa
+
+As for sympa, that's a particular exception in that it uses the same
+email address as an identity token and as an contact address (or could
+it authenticate against a primary email address and use a second one,
+returned by the directory, to post mails to? requires sync from time
+to time). It is tricky (but no unfeasible I guess, it just asks the
+problem to be properly laid out) and I would leave the sympa setup
+separate at first, with the possibility to later make a soft link
+between a LDAP account (being able to ask sympa "for this email, what
+do you have?") and experiment safely with a proper integration. This
+just to move forward withouth putting too long a delay on production
+release. That would mean, at first, let people authenticate/subscribe
+on Sympa using only local Sympa db.
+
+
+#4. Email as an id
+
+As to objections on using the email as an id:
+ * I didn't mean that forum should use local accounts instead of LDAP
+ones, the contrary actually; what it takes is that the account
+registration procedure must be routed to identity, instead of the
+regular forum process; and that the forum auth mechanism must handle
+on-the-fly creation of a local account from a valid LDAP account;
+ * I am not sure to see the issue with gmane/mail archive?
+ * if having a big LDAP is an issue (why would it be?) then LDAP is
+not the solution for a central auth directory (and that would be
+ironic somehow)
+ * using email as a login, we obviously must have emails editable
+separately in LDAP, test their unicity within their own scope (being a
+primary email, or a secondary one is not the same), should have a
+validity status from one (that is, making sure someone ends up reading
+a message posted to it).
+ * when we decided to use the email as the id for Mandriva web
+services, the biggest problem that arose in the end was: would it work
+for authenticated HTTP urls, like:
+https://user@domain.tld:password@server.domain.tld/ (so it would work
+for private downloads)? It does (wget does it; curl has hiccups about
+it that can be easily worked out (escape the first @ or parse the url
+to provide ids as arguments)).
+
+I don't think we should provide @mageia.org email at large, for the
+same arguments as misc's.
+
+
+
+
+The view I exposed above adds contraints, but has several benefits:
+ * a single/consistent repository/auth mechanism for all users and for all apps
+ * it forces apps to manage all user accounts the same way (will help
+for mashing up their data and making it possible to them to manage
+them in a consistent way); we can define levels of features for apps
+about this;
+ * users get a more complete profile upon their roles within the project
+
+Cheers,
+
+Romain
+
+On Wed, Nov 24, 2010 at 18:54, Michael Scherer <misc at zarb.org> wrote:
+> [...]
+> So to summarize :
+> - can someone confirm we can do this for sympa ?
+>
+> - does someone see a problem with the proposed scheme for sympa, and
+> does it fulfill everybody need ?
+>
+> - does everybody agree for the separation in 2 category of applications,
+> and the consequence for the application in term of authentication ?
+