diff options
Diffstat (limited to 'zarb-ml/mageia-sysadm/2010-November/000963.html')
-rw-r--r-- | zarb-ml/mageia-sysadm/2010-November/000963.html | 187 |
1 files changed, 187 insertions, 0 deletions
diff --git a/zarb-ml/mageia-sysadm/2010-November/000963.html b/zarb-ml/mageia-sysadm/2010-November/000963.html new file mode 100644 index 000000000..6855ee544 --- /dev/null +++ b/zarb-ml/mageia-sysadm/2010-November/000963.html @@ -0,0 +1,187 @@ +<!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%20authentication&In-Reply-To=%3C1290732472.2069.268.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="000950.html"> + <LINK REL="Next" HREF="000964.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication</H1> + <B>Michael Scherer</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%20authentication&In-Reply-To=%3C1290732472.2069.268.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication">misc at zarb.org + </A><BR> + <I>Fri Nov 26 01:47:52 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="000950.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000964.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#963">[ date ]</a> + <a href="thread.html#963">[ thread ]</a> + <a href="subject.html#963">[ subject ]</a> + <a href="author.html#963">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le jeudi 25 novembre 2010 à 22:40 +0100, nicolas vigier a écrit : +><i> On Thu, 25 Nov 2010, Michael Scherer wrote: +</I>><i> +</I>><i> > > > - using email as login is dangerous. Since the email is freely editable +</I>><i> > > > in catdap ( and multivalued ), someone could perfectly change his email +</I>><i> > > > after opening a account, and thus get access to sympa subscription of +</I>><i> > > > someone else. +</I>><i> > > +</I>><i> > > And lose their account to the user whose email address was used as soon as we +</I>><i> > > allow user-initiated password reset ... +</I>><i> > +</I>><i> > Which is not a problem, since opening a account is free. If we start to +</I>><i> > have some private mls ( such as the one requested for forums ), reading +</I>><i> > archive would be a privacy issue, and so step must be taken to prevent +</I>><i> > that. +</I>><i> > +</I>><i> > But my main point is not this particular example who is quite easy to +</I>><i> > prevent. But rather that 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>><i> > +</I>><i> > Editing by admin should be ok. +</I>><i> +</I>><i> To avoid this, I think email should not be freely editable in catdat, +</I>><i> but should be verified first before being actually changed in ldap. +</I>><i> When changing email, the user should receive on the new email an URL +</I>><i> to open to confirm he is the owner of the email. +</I> + +So to summarize, here is a updated proposal ( order matter ) : + +- use username as primary login, not letting people change it for now. +Since most applications may not properly support it, I feel it would be +safer. + +- make sure that catdap can take username or email when resetting +password. ie : +reset password : + - email or username : + [send the request] + +this will likely be enough for people who forget their username, IMHO. + +- make sure primary email is unique, by setting it in ldap as such. +( quite easy ) + +- allow to also use emails as login for all applications that support it +now. Ie username and primary email ( since it is easier to have it +unique ). Yet the username will still be the username showed, or the cn +if the application support it ( or displayName ). + +Ie, even if I used <A HREF="https://www.mageia.org/mailman/listinfo/mageia-sysadm">michael at example.org</A>, it would show "welcome Michael +Scherer" ( or welcome misc, if the application do not support getting +the CN or DisplayName or a custom attribute ). + +So far, sympa support it. Not sure for the others. + + +- For those that don't, try to patch them _and_ get the patch accepted +by upstream first ( because that's already enough work to write the +patch so if it is not even accepted upstream, we will have to maintain +it and that's not good from a deployment pov ). Backporting the patch +would be ok, carrying it forever is IMHO not desirable. But theses +features seems generic enough to be a welcome addition that can be +upstreamed. + +Features being "using email and/or username" and/or "showing +CN/DisplayName instead of username". + + + +- find a way to ensure unicity of email for the secondary emails that +user can enter. If possible, on the ldap level directly, but maybe doing +it on catdap level would be enough. I would feel safer to have this at +ldap level for obvious reasons of data integrity. + + +- once we have enabled and checked it, and ensured that this is not a +potential source of problem, enable the use of the secondary email as a +login, in addition to username and primary email + +( this should not requires much patching of application, but if needed, +same rule as previously apply ). + + +- ensure that aliases @mageia.org can also be used without being entered +in the ldap ( may requires some black magic at ldap level ). But if we +can't, just let people add it by themself, or add it when user get their +email aliases. + + +- The username will be used by application as the "primary key" in their +local db. So people can change their email without trouble, and we will +not need to touch to the application too much when it happens. +( or at least I hope ) + +Later, if we decide this is worthwhile, and if there is demand for it +( but if we let change email and display name, username may not require +change ), we have enough ressources ( because I think that would be a +issue for the moment ), we can start to check for a way of changing +username on the whole information system. + + +So I think this plan of action will satisfy everybody : +- people can use their email or their username +- people can change their emails without impacting the db, and without +requiring invasive change ( and with upstreamable patchs ) +- people can change the information that is displayed, and patchs could +also be sent upstream. +- we do not have much burden of maintaining it ( as we use standard +protocols ) +- we can roll out the required feature one at a time, so nothing get +late, and we have the full time to work on it and properly finish the +adaptation of others softwares + +Bonus points : +- we have small patchs and features to code, so we can fill the junior +job list +- we can also communicate frequently on progress + +I didn't included oauth/openid/SSO/etc in the plan, as +- this seems much more like a much more distant goal +- much more invasive on all levels +- something that I still didn't grasp + + +So, is everybody ok with this plan ? + +-- +Michael Scherer + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000950.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000964.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#963">[ date ]</a> + <a href="thread.html#963">[ thread ]</a> + <a href="subject.html#963">[ subject ]</a> + <a href="author.html#963">[ 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> |