diff options
Diffstat (limited to 'zarb-ml/mageia-sysadm/2010-November/000940.html')
| -rw-r--r-- | zarb-ml/mageia-sysadm/2010-November/000940.html | 306 |
1 files changed, 306 insertions, 0 deletions
diff --git a/zarb-ml/mageia-sysadm/2010-November/000940.html b/zarb-ml/mageia-sysadm/2010-November/000940.html new file mode 100644 index 000000000..82b3bea77 --- /dev/null +++ b/zarb-ml/mageia-sysadm/2010-November/000940.html @@ -0,0 +1,306 @@ +<!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=%3C1290707666.2069.189.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="000915.html"> + <LINK REL="Next" HREF="000945.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=%3C1290707666.2069.189.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication">misc at zarb.org + </A><BR> + <I>Thu Nov 25 18:54:26 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="000915.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000945.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#940">[ date ]</a> + <a href="thread.html#940">[ thread ]</a> + <a href="subject.html#940">[ subject ]</a> + <a href="author.html#940">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le jeudi 25 novembre 2010 à 10:50 +0100, Buchan Milne a écrit : +><i> On Wednesday, 24 November 2010 18:54:40 Michael Scherer wrote: +</I> +><i> > So the first proposal that I will expose : +</I>><i> > +</I>><i> > - users will use their personal email address and the password from ldap +</I>><i> > to authenticate themselves. +</I>><i> +</I>><i> Is this a limitation in sympa? All LDAP-capable software should allow +</I>><i> configuration of which attribute to authenticate against ... +</I> +Of course we can, but my goal was to list the various proposal that I +have understood to be proposed ( maybe they were not, but then I hope +the people who complain about me misrepresenting them will volunteer +next time :) + +For sympa, it can fetch the mail from the dn, and the dn from the login, +so we can perfectly avoid using email in login. + +><i> > While this is the easiest solution ( and the current one in svn from +</I>><i> > what I understood ), this idea suffer from 3 issues : +</I>><i> > +</I>><i> > - people will use a different login than the one of identity. +</I>><i> +</I>><i> Why? We can change identity to search for the username in the mail attribute. +</I>><i> We can even probably allow login with either uid or mail. In fact, it should +</I>><i> only be a configuration change to set user_filter in catdap_local.yml. It +</I>><i> isn't entirely, I will commit a ~ 10 line patch to fix hardcoding of +</I>><i> attributes/filters in user.pm shortly. +</I> +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. + +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. + +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 ). + +So we should use the username, as this is mean to do that. + +><i> > This is +</I>><i> > not really how a centralized login system should work, imho. And this +</I>><i> > was a source of confusion ( at least, of my confusion ) at Mandriva. +</I>><i> > +</I>><i> > - people will need to open a account on identity. For some applications, +</I>><i> > this may not be desirable. For example, on a forum, having to first +</I>><i> > register, and then log on the forum to fill the data is not good. +</I>><i> +</I>><i> Normally, the user has to register on a forum anyway, activate the account, +</I>><i> before changing avatar or anything. So, I don't see the difference. +</I>><i> As long as +</I>><i> the forum has been configured to send users to identity to register, there +</I>><i> shouldn't be too much inconvenience. We could try and redirect the user to the +</I>><i> forum login after activation to make it a bit easier. +</I> +That's still a 2 step procedure instead of 1. But I am not the one who +indeed would complain of that. And given that a account creation is a +rare event ( in a user timeline ), that's not a big problem. + +A redirection to the service would indeed be a welcome addition. You +know what to add on the TODO list. + +><i> > For +</I>><i> > mailling list, if we intend to subscribe gmane, or mail archive to the +</I>><i> > list, this is not good either. I couldn't get in touch with rda in time, +</I>><i> > but I think that's what he meant ( if not, romain, feel free to correct +</I>><i> > me ). And in fact, this would also put more pressure on ldap than +</I>><i> > intended ( if we requires this for forum, we may end with a big ldap +</I>><i> > directory ). +</I>><i> +</I>><i> AFAIK, the forum only impacts LDAP on login to the forum, not on every page +</I>><i> view etc. +</I> +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 was under the +impression that this kind of directory would requires more ressources +than what we planned. Or at least, to me, it is out of the "this will do +it without trouble" range. And since I do not remind that we did a +formal ressources planning, unless it was not widely published ( and in +this case, it should be more visible ), it seemed a lot to me. + +But maybe I am worried for nothing ( since I still live in a world where +1 gb of ram is a huge amount for a server :/ ). + + +><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> +Which is not a problem, since opening a account is free. If we start to +have some private mls ( such as the one requested for forums ), reading +archive would be a privacy issue, and so step must be taken to prevent +that. + +But my main point is not this particular example who is quite easy to +prevent. But rather that 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. + +Editing by admin should be ok. + +><i> > More ever, nothing guarantee that email are uniques +</I>><i> > across the whole DIT, especially if email span on 2 attributes ( mail +</I>><i> > and mailAlternateAddress ). +</I>><i> +</I>><i> mail is multi-valued, we should have a policy on how we maintain this. At +</I>><i> present, I don't see if we need mailAlternateAddress. However, if we maintain +</I>><i> all email addresses in 'mail' attribute, we can apply slapo-unique to easily +</I>><i> prevent this. +</I> +I could see a reason : + +We need to have at least 1 attribute who is the mail for which we will +forward if we set aliases ( and we will, I think we all expect them ), +who should not be multivalued. + +And we need another attribute for the email the user entered on first +login, so we know where to send a new password request. + +And a 3rd attribute to handle the email in a potential vcard-like +system. + +1st attribute should not be multiValued. +2nd shouldn't either. +3rd should be, but we could decide it is not. + +So, my understanding is that mail is 2nd, mailAlternateAddress is the +3rd, and mailForwardingAddress is the 1st ( but a quick look at schema +do not seems to confirm this, so again, I may be wrong ). + +We could reduce that to 2 attributes : +- mail act for 2 and 1, not multivalued +- mailAlternateAdress act for 3, multivalued + +or : +- mail act for 3 +- mailForwardingAddress act for 1, +and we do not use anything for 2 ( like either using all mail of 3, or +just 1 ). + +I would favor the first scheme. + +In fact, I would even favor some system where mail mean the email people +use to receive mail for ml, and mailAlternateAdress are email that +people can use to post ( so the day I am not awake and start to use my +personal mail, I have no problem of being moderated ). But I disgress, +this has nothing to do with auth. + +><i> > So what I propose to solve this is the following scheme : +</I>><i> > +</I>><i> > A user wanting to authenticate on sympa will provide a login, who will +</I>><i> > be either : +</I>><i> > - a email ( his personal email or email of choice ) + password of his +</I>><i> > choice, stored by sympa, and using regular sympa authentication +</I>><i> > or +</I>><i> > - a login ( identity login ) + password from ldap +</I>><i> > +</I>><i> > If I understood correctly, sympa support this +</I>><i> > ( <A HREF="http://www.sympa.org/manual_6.1/authentication">http://www.sympa.org/manual_6.1/authentication</A> ). +</I>><i> > +</I>><i> > This way : +</I>><i> > 1) we do not force identity on anybody +</I>><i> +</I>><i> ? +</I> +Ie, people can subscribe without using identity. + +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. + +><i> > 2) the login is either a email ( with email verification done by sympa, +</I>><i> > and email change also done by sympa ) or our fixed ldap login ( fixed, +</I>><i> > ie, not under the control of any user ) +</I>><i> +</I>><i> We need to chose one ... +</I> +Sympa could support both, and that's what made me think of the dual auth +proposal ( this and the proposal of maat ). ( and Bugzilla also +supported some kind of fallback to local account ). + +><i> > 3) people will use the same uid everywhere ( because having sometime the +</I>><i> > email, sometime the uid is confusing, especially if we start to offer +</I>><i> > email alias ) +</I>><i> +</I>><i> I had assumed this would be the strategy from the beginning. +</I> +Well, some people didn't, or at least, this was my impression ( but it +seems that I was wrong ). + +For example, IIRC, one of the few things maat told us about the forum +was the dual auth scheme ( I cannot find reference however so maybe I +dreamed ). I was also under the impression than rda didn't want people +to be in a team to subscribe on ml, which I interpreted by "people +should not open a account on ldap to subscribe on ml" ( but that was a +misunderstanding ). + +So if nobody is against it, then yes, we should use ldap. + +It is more standard ( so no special knowledge, nor special changes on +anything ), more simple ( just 1 directory ), and so likely more robust +( as this already widely deployed ). + +So, indeed, another proposal is : + +- 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. + +( 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 ), maintainability ( hook/script to modify the data on every +impacted web applications, dependant on internal structure of the +application ) and engineering ( fragile if there is no commit/rollback ) +points of view ) + +- we filter on team when needed + + + +-- +Michael Scherer + +</PRE> + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000915.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000945.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#940">[ date ]</a> + <a href="thread.html#940">[ thread ]</a> + <a href="subject.html#940">[ subject ]</a> + <a href="author.html#940">[ 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> |