diff options
Diffstat (limited to 'zarb-ml/mageia-sysadm/2010-November/000951.html')
| -rw-r--r-- | zarb-ml/mageia-sysadm/2010-November/000951.html | 201 |
1 files changed, 201 insertions, 0 deletions
diff --git a/zarb-ml/mageia-sysadm/2010-November/000951.html b/zarb-ml/mageia-sysadm/2010-November/000951.html new file mode 100644 index 000000000..b4339cbb5 --- /dev/null +++ b/zarb-ml/mageia-sysadm/2010-November/000951.html @@ -0,0 +1,201 @@ +<!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=%3C201011251122.50618.bgmilne%40multilinks.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="000899.html"> + <LINK REL="Next" HREF="000915.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication</H1> + <B>Buchan Milne</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=%3C201011251122.50618.bgmilne%40multilinks.com%3E" + TITLE="[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication">bgmilne at multilinks.com + </A><BR> + <I>Thu Nov 25 11:22:50 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="000899.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000915.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#951">[ date ]</a> + <a href="thread.html#951">[ thread ]</a> + <a href="subject.html#951">[ subject ]</a> + <a href="author.html#951">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Wednesday, 24 November 2010 20:29:04 Romain d'Alverny wrote: +><i> Hi, +</I>><i> +</I>><i> thanks for the long description. Instead of replying point by point, I +</I>><i> would like to suggest a more radical point of view, that actually +</I>><i> determined the my.mandriva setup (that would not make a difference +</I>><i> between "regular" users and "active" users from a auth/storage POV). I +</I>><i> think it's worth it to discuss it as well. +</I>><i> +</I>><i> The rationale is to ease the user flow through the project, as a +</I>><i> whole. 4 points below. +</I>><i> +</I>><i> #1. General rule: all users authenticate the same way against a single +</I>><i> directory +</I> +IMHO this is non-negotiable. + +><i> #2. Consequences +</I>><i> +</I>><i> That means that identity should authenticate with email preferably +</I>><i> (but may allow using the login). +</I> +Most applications can be configured to authenticate on any LDAP attribute. +This is more of a policy/usability issue than a technical one. + +><i> That does not prevent that local app data is locally stored. +</I> +Only non-application-specific should be in the directory. Application-specific +user data stays in the application. + +><i> That's +</I>><i> how my.mandriva scheme was designed (and could have gone further). +</I>><i> That does not prevent that local apps provide a way for the user to +</I>><i> build a mashup of all data around (for a reporting/activity/social net +</I>><i> app for instance). +</I>><i> +</I>><i> That means that any user using any part of the Mageia infrastructure +</I>><i> has to get an account through identity.mageia.org. And that +</I>><i> email/login must be tested for unicity. +</I> +At present we are only using uid for login, which is unique-enforced (as it is +the RDN). + +><i> That also puts some constraints on how an app manages authentication +</I>><i> and local user data: +</I>><i> * it must be able to authenticate from an outside source +</I>><i> * it must be able to manage primary email change (we used a +</I>><i> "customer_id" at Mandriva, a 64 char id that allowed to change both +</I>><i> email and login at will without losing user reference; would that +</I>><i> match the uid?) +</I> +It would be possible to rename the user account, but most applications will be +using the "login" as the key to store preferences. LDAP has entryUUID to allow +tracking of entries across renames, but ... most application supporting LDAP +authentication will use the login name for keying user information. Getting +applications to use a different attribute for this is more of a challenge. + +How important is it to be able to allow changes to the 'login'? + +(Of course, this motivates against using email address as login). + +><i> * it must be able to update, if needed, locally cached data that +</I>><i> source from the central repository. +</I>><i> +</I>><i> To some extent, it could even have the ability to manage a central +</I>><i> session server, but that may be left for a later time (and can +</I>><i> actually be managed almost separately once the central auth is done). +</I>><i> +</I>><i> (we may use OAuth and OpenID auth at a later time for web apps. That +</I>><i> shouldn't have an impact on the above (and below) authentication +</I>><i> scheme anyway) +</I>><i> +</I>><i> So what about apps that do not support this scheme? We patch them so +</I>><i> they do (and we do it the clean way). Puts more constraints on the +</I>><i> dev/admin side, for sure; but again, the rationale is to provide a +</I>><i> consistent interface to the user with easiest to remember items (email +</I>><i> then, instead of login). And that forces us to find a consistent +</I>><i> protocol that is already (or should be) implemented in our apps. +</I> +Cost/benefit for supporting login changes? + +><i> #3. Sympa +</I>><i> +</I>><i> As for sympa, that's a particular exception in that it uses the same +</I>><i> email address as an identity token and as an contact address (or could +</I>><i> it authenticate against a primary email address and use a second one, +</I>><i> returned by the directory, to post mails to? requires sync from time +</I>><i> to time). It is tricky (but no unfeasible I guess, it just asks the +</I>><i> problem to be properly laid out) and I would leave the sympa setup +</I>><i> separate at first, with the possibility to later make a soft link +</I>><i> between a LDAP account (being able to ask sympa "for this email, what +</I>><i> do you have?") and experiment safely with a proper integration. This +</I>><i> just to move forward withouth putting too long a delay on production +</I>><i> release. That would mean, at first, let people authenticate/subscribe +</I>><i> on Sympa using only local Sympa db. +</I>><i> +</I>><i> +</I>><i> #4. Email as an id +</I>><i> +</I>><i> As to objections on using the email as an id: +</I>><i> * I didn't mean that forum should use local accounts instead of LDAP +</I>><i> ones, the contrary actually; what it takes is that the account +</I>><i> registration procedure must be routed to identity, instead of the +</I>><i> regular forum process; and that the forum auth mechanism must handle +</I>><i> on-the-fly creation of a local account from a valid LDAP account; +</I> +I logged in to the test forum setup with only my account in LDAP, without +problems. So, only username/password aspects (registration, password change, +password reset) must be redirect to identity. Bugzilla is already configured +to reject password change or registration, with a message to visit +identity.mageia.org. + +><i> * I am not sure to see the issue with gmane/mail archive? +</I>><i> * if having a big LDAP is an issue (why would it be?) then LDAP is +</I>><i> not the solution for a central auth directory (and that would be +</I>><i> ironic somehow) +</I> +Uh, we agreed earlier that we would have at least one slave, which would be +used for internet-facing stuff, and at least one directory server (e.g. +master) which is not used for internet-facing stuff, to ensure admin access +works even in the case of a DoS. + +><i> * using email as a login, we obviously must have emails editable +</I>><i> separately in LDAP, test their unicity within their own scope (being a +</I>><i> primary email, or a secondary one is not the same), should have a +</I>><i> validity status from one (that is, making sure someone ends up reading +</I>><i> a message posted to it). +</I>><i> * when we decided to use the email as the id for Mandriva web +</I>><i> services, the biggest problem that arose in the end was: would it work +</I>><i> for authenticated HTTP urls, like: +</I>><i> <A HREF="https://user@domain.tld:password@server.domain.tld/">https://user@domain.tld:password@server.domain.tld/</A> (so it would work +</I>><i> for private downloads)? It does (wget does it; curl has hiccups about +</I>><i> it that can be easily worked out (escape the first @ or parse the url +</I>><i> to provide ids as arguments)). +</I> +Consider though using a modifiable attribute as the key for storing all other +applications configuration. + +><i> I don't think we should provide @mageia.org email at large, for the +</I>><i> same arguments as misc's. +</I> +This is an issue unrelated to LDAP and what attribute to use for +authentication IMHO, but has implications for LDAP (alias maps etc.). + +Regards, +Buchan +</PRE> + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000899.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000915.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#951">[ date ]</a> + <a href="thread.html#951">[ thread ]</a> + <a href="subject.html#951">[ subject ]</a> + <a href="author.html#951">[ 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> |