diff options
Diffstat (limited to 'zarb-ml/mageia-sysadm/2010-November/000899.html')
| -rw-r--r-- | zarb-ml/mageia-sysadm/2010-November/000899.html | 219 |
1 files changed, 219 insertions, 0 deletions
diff --git a/zarb-ml/mageia-sysadm/2010-November/000899.html b/zarb-ml/mageia-sysadm/2010-November/000899.html new file mode 100644 index 000000000..7be97faca --- /dev/null +++ b/zarb-ml/mageia-sysadm/2010-November/000899.html @@ -0,0 +1,219 @@ +<!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=%3CAANLkTin5Zj9GQnP9iQjiDM7t5v0qyrksWiDUHivrPLoN%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="000897.html"> + <LINK REL="Next" HREF="000951.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=%3CAANLkTin5Zj9GQnP9iQjiDM7t5v0qyrksWiDUHivrPLoN%40mail.gmail.com%3E" + TITLE="[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication">rdalverny at gmail.com + </A><BR> + <I>Wed Nov 24 20:29:04 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="000897.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000951.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#899">[ date ]</a> + <a href="thread.html#899">[ thread ]</a> + <a href="subject.html#899">[ subject ]</a> + <a href="author.html#899">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>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: +<A HREF="https://user@domain.tld:password@server.domain.tld/">https://user@domain.tld:password@server.domain.tld/</A> (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 <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-sysadm">misc at zarb.org</A>> wrote: +><i> [...] +</I>><i> So to summarize : +</I>><i> - can someone confirm we can do this for sympa ? +</I>><i> +</I>><i> - does someone see a problem with the proposed scheme for sympa, and +</I>><i> does it fulfill everybody need ? +</I>><i> +</I>><i> - does everybody agree for the separation in 2 category of applications, +</I>><i> and the consequence for the application in term of authentication ? +</I></PRE> + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000897.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000951.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#899">[ date ]</a> + <a href="thread.html#899">[ thread ]</a> + <a href="subject.html#899">[ subject ]</a> + <a href="author.html#899">[ 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> |