diff options
Diffstat (limited to 'zarb-ml/mageia-sysadm/2010-November/000915.html')
| -rw-r--r-- | zarb-ml/mageia-sysadm/2010-November/000915.html | 323 |
1 files changed, 323 insertions, 0 deletions
diff --git a/zarb-ml/mageia-sysadm/2010-November/000915.html b/zarb-ml/mageia-sysadm/2010-November/000915.html new file mode 100644 index 000000000..ab4ce529c --- /dev/null +++ b/zarb-ml/mageia-sysadm/2010-November/000915.html @@ -0,0 +1,323 @@ +<!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=%3C201011251050.44679.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="000951.html"> + <LINK REL="Next" HREF="000940.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=%3C201011251050.44679.bgmilne%40multilinks.com%3E" + TITLE="[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication">bgmilne at multilinks.com + </A><BR> + <I>Thu Nov 25 10:50:44 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="000951.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000940.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#915">[ date ]</a> + <a href="thread.html#915">[ thread ]</a> + <a href="subject.html#915">[ subject ]</a> + <a href="author.html#915">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Wednesday, 24 November 2010 18:54:40 Michael Scherer wrote: +><i> Hi, +</I>><i> +</I>><i> as proposed during previous founders meeting, we need to be clear upon +</I>><i> how we want to use authentication on web applications ( and non web +</I>><i> too ) with regard to ldap directory. +</I>><i> +</I>><i> So what I propose will apply to sympa, but could be expended on others +</I>><i> applications. +</I>><i> +</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> +Is this a limitation in sympa? All LDAP-capable software should allow +configuration of which attribute to authenticate against ... + +><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> +Why? We can change identity to search for the username in the mail attribute. +We can even probably allow login with either uid or mail. In fact, it should +only be a configuration change to set user_filter in catdap_local.yml. It +isn't entirely, I will commit a ~ 10 line patch to fix hardcoding of +attributes/filters in user.pm shortly. + +><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> +Normally, the user has to register on a forum anyway, activate the account, +before changing avatar or anything. So, I don't see the difference. As long as +the forum has been configured to send users to identity to register, there +shouldn't be too much inconvenience. We could try and redirect the user to the +forum login after activation to make it a bit easier. + +><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> +AFAIK, the forum only impacts LDAP on login to the forum, not on every page +view etc. + +><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> +And lose their account to the user whose email address was used as soon as we +allow user-initiated password reset ... + +><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> +mail is multi-valued, we should have a policy on how we maintain this. At +present, I don't see if we need mailAlternateAddress. However, if we maintain +all email addresses in 'mail' attribute, we can apply slapo-unique to easily +prevent this. + +><i> We could however 1) check the unicity of email on ldap 2) modify catdap +</I>><i> to requires a confirmation before changing anything email related. +</I>><i> +</I>><i> +</I>><i> So then a second proposal was done : +</I>><i> - users use their @mageia.org alias, and the password from ldap +</I>><i> +</I>><i> this one fix the 3rd issue, to be replaced by a 4th and 5th ones : +</I>><i> +</I>><i> - everybody who will open a account on identity will receive a alias. +</I>><i> I am not sure that's what we should propose, especially since a alias is +</I>><i> like a official acknowledgment. And we do not want to restrict ml to the +</I>><i> few people that would receive a alias. +</I> +Let's have a policy on aliases before we make decisions that require or +prevent them ... + +><i> - people will need to use the alias to post on the ml, or we will need +</I>><i> to find a way to find their emails from their subscriptions. Not sure if +</I>><i> sympa could do it ( but this would be great ) +</I>><i> +</I>><i> But issue 1 and 2 still apply. +</I>><i> +</I>><i> +</I>><i> For the sake of being complete, we could also decide to not use ldap. +</I>><i> Then we would lose the centralisation of password, and that's imho +</I>><i> something to avoid if we can. But that's still a option that we should +</I>><i> not forget. +</I>><i> +</I>><i> +</I>><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> 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> +We need to chose one ... + +><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 had assumed this would be the strategy from the beginning. + +><i> +</I>><i> So, that's the first part of my mail. +</I>><i> +</I>><i> +</I>><i> This issue with ldap integration will likely arise on almost every web +</I>><i> application we will setup. So I would like to propose the following : +</I>><i> +</I>><i> we have 2 types of applications : +</I>><i> - some are for use of active people +</I>><i> - submit packages, send something on svn +</I>><i> - wiki edition ( not sure on this one ) +</I>><i> - transifex +</I>><i> - maintainers db +</I>><i> - etc +</I>><i> +</I>><i> For those applications, we would likely require be in a team first which +</I>><i> should IMHO require a account in identity. +</I> +Well, if *all* accounts are already in identity, the user just needs to join +the team (if we restrict access to some apps to some teams, e.g. transifex). + +><i> +</I>><i> - some are for the use of the enlarged community +</I>><i> - forums +</I>><i> - mailing lists +</I>><i> - bugzilla +</I>><i> - etc +</I>><i> +</I>><i> Those should not requires to be in a team first, and therefore, do not +</I>><i> require a account in identity. +</I> +But, why should we require them to have another account if they filed a bug +about localisation, then offered to be the translator for their language to +fix the bug ... + +><i> +</I>><i> Yet, we want to have the benefit of the central authentication as much +</I>><i> as possible. +</I>><i> +</I>><i> So let's divide applications in 2 category : +</I>><i> +</I>><i> The one in the 1st will use ldap authentication only. That's quite easy +</I>><i> to achieve most of the time. Of course, supporting ldap is not the only +</I>><i> thing we want when selecting a application. Being able to support +</I>><i> filter, show meaningful errors messages, and others are also to +</I>><i> consider. +</I>><i> +</I>><i> The one in the 2nd will use some kind of hybrid auth, if possible. Ie, +</I>><i> if people give a ldap login ( uid + password ), the access is granted, +</I>><i> and if not, we do a fallback on some kind of native and non centralized +</I>><i> login system. +</I> +IMHO, this is more trouble than it is worth, and more trouble than having all +users on LDAP. + +><i> +</I>><i> However this will open a can of worms : +</I>><i> - what about possible login conflict, ie, how can we prevent someone +</I>><i> from using "misc" ( for example ) as a login in the native users +</I>><i> database ? What would happen if the conflict arise ? +</I>><i> +</I>><i> Forcing people to use their email is a solution, but not everything +</I>><i> support that model. We can't simply check if the login is not in use +</I>><i> because someone could perfectly use it later. +</I>><i> +</I>><i> - what people who first open a account on the software, and later change +</I>><i> to use a identity login ? How can we merge the 2 ( especially if there +</I>><i> is some authorization issue ) ? +</I>><i> +</I>><i> This would likely requires hand edition by a admin of the DB or +</I>><i> equivalent. +</I> +All these are reasons to have a single authentication store. Rememeber, you +would have these problems anyway, if you had no LDAP, and is in fact the +problem we are trying to avoid by using LDAP. + +><i> - what about a software that do not support it, ie ldap or native, but +</I>><i> not both ? Or that do not support it as we want ? +</I> +We file bugs, supply patches, or choose other software that is suitable. + +><i> So far, bugzilla support this ( ldap, and fallback on the DB ), maat +</I>><i> told me this was the proposed scheme for forum ( iirc ) and that's the +</I>><i> one I propose for sympa. So at least, for the example I gave, we are ok. +</I>><i> +</I>><i> +</I>><i> and the biggest problem ( imho ) : +</I>><i> +</I>><i> How do we decide what category does a application belong ? +</I> +We have one category, must support LDAP, and if access should be restricted, +it must support LDAP authorization by group or filter (if only filter, then we +may need to add memberof overlay). + +><i> Some are quite easy, and some are more difficult ( I think ). For +</I>><i> example, I would be inclined to use ldap login for the wiki, or let +</I>><i> people be unauthenticated. Maybe not everybody agree. +</I>><i> +</I>><i> What about application like mageia-app-db ? +</I>><i> This one is easier since we can specifically add this as requirement. +</I> +I would say that anonymous access (just browsing packages) should be allowed. +If users are to have personalised features, then maybe you would want to +integrate some data or links from/to other applications that authenticate + +><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> +Which proposed scheme? Using uid as username? + +><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> +I see no reason to have two categories. Please explain exactly how having +every single user who interacts with Mageia in any fashion on LDAP is a +problem. + +My idea was to make it as *easy* as possible for people to manage their +relationships to Mageia. So, users register once, and use that account for all +"public" access (forum, mailing list, bugzilla, wiki). If a user becomes a +contributor, we upgrade their account as necessary, but there is no big +obstacle, no disruption etc. to the user. + +Regards, +Buchan +</PRE> + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000951.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI>Next message: <A HREF="000940.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#915">[ date ]</a> + <a href="thread.html#915">[ thread ]</a> + <a href="subject.html#915">[ subject ]</a> + <a href="author.html#915">[ 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> |