diff options
| author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
|---|---|---|
| committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
| commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
| tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-sysadm/2011-April/003372.html | |
| parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
| download | archives-1be510f9529cb082f802408b472a77d074b394c0.tar archives-1be510f9529cb082f802408b472a77d074b394c0.tar.gz archives-1be510f9529cb082f802408b472a77d074b394c0.tar.bz2 archives-1be510f9529cb082f802408b472a77d074b394c0.tar.xz archives-1be510f9529cb082f802408b472a77d074b394c0.zip | |
Diffstat (limited to 'zarb-ml/mageia-sysadm/2011-April/003372.html')
| -rw-r--r-- | zarb-ml/mageia-sysadm/2011-April/003372.html | 244 |
1 files changed, 244 insertions, 0 deletions
diff --git a/zarb-ml/mageia-sysadm/2011-April/003372.html b/zarb-ml/mageia-sysadm/2011-April/003372.html new file mode 100644 index 000000000..1513ef7d5 --- /dev/null +++ b/zarb-ml/mageia-sysadm/2011-April/003372.html @@ -0,0 +1,244 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-sysadm] Users authentication on forums + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20Users%20authentication%20on%20forums&In-Reply-To=%3C1303168244.10561.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="003332.html"> + <LINK REL="Next" HREF="003400.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-sysadm] Users authentication on forums</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20Users%20authentication%20on%20forums&In-Reply-To=%3C1303168244.10561.189.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-sysadm] Users authentication on forums">misc at zarb.org + </A><BR> + <I>Tue Apr 19 01:10:44 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="003332.html">[Mageia-sysadm] Users authentication on forums +</A></li> + <LI>Next message: <A HREF="003400.html">[Mageia-sysadm] Users authentication on forums +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#3372">[ date ]</a> + <a href="thread.html#3372">[ thread ]</a> + <a href="subject.html#3372">[ subject ]</a> + <a href="author.html#3372">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 11 avril 2011 à 14:39 +0200, nicolas vigier a écrit : +><i> Hello, +</I>><i> +</I>><i> For authentication on the forums, we are currently using ldap. The user +</I>><i> sends his login and passwords to phpbb which use it to authenticate on +</I>><i> ldap server. Because of this, someone with root access on the forums +</I>><i> server can access password of any user connecting to the forums. And +</I>><i> because important passwords are transfered, the connection needs to be +</I>><i> in SSL, so the *.mageia.org certificate also needs to be installed. So +</I>><i> access to the server needs to be restricted to sysadmin team only, who +</I>><i> also need to be able to check what is being done on forums, check it is +</I>><i> secure, etc ... And I think this makes forums admins not happy. +</I> +Then what about doing like french forums, and not connect at all to our +ldap. + +This let people the whole freedom to do what they want and allow us to +focus on stuff that we need ( like deploying everything that need to be +deployed, wiki, bittorrent server, etc, see the bugzilla for list of +thing to do ). + + +><i> As we are using ldap for authentication only (not for groups or anything +</I>><i> else), +</I> +Usage of group have been proposed in the council meeting tonight. ( for +having a specific tag on forum ). So ldap access would enable this. + + +><i> I think we could do authentication differently. Maybe we could +</I>><i> setup a mageia OpenID server linked to the ldap server. Then on the +</I>><i> forums use OpenID for authentication, when a user enter his login on +</I>><i> the forums he is redirected to the mageia OpenID authentication page +</I>><i> for the login entered. Then we can disable https on the forums, and +</I>><i> forum admins can be root on the forums server. And passwords are better +</I>><i> protected in case phpbb has a vulnerability. +</I> +Or in case someone go rogue, or has his privileged account compromised. + +><i> Sysadmin team would manage openid server. And forum team would manage +</I>><i> forums server. +</I>><i> +</I>><i> I've seen this project for phpbb3 openid authentication (I didn't check +</I>><i> if there are others) : +</I>><i> <A HREF="http://sourceforge.net/projects/phpbb-openid/">http://sourceforge.net/projects/phpbb-openid/</A> +</I>><i> +</I>><i> Login form looks like this : +</I>><i> <A HREF="http://sourceforge.net/dbimage.php?id=91989">http://sourceforge.net/dbimage.php?id=91989</A> +</I>><i> We would need to modify it to remove Username/Password. Replace "OpenID" +</I>><i> with "Mageia login" and automatically use Mageia OpenID server with the +</I>><i> login entered. So that each account on the forum is still linked to a +</I>><i> Mageia account. +</I> +Well, I foresee some problems. People not wanting the exact rational can +just skip to the end, there is a quick summary : + +- we would need to make changes to applications, in a non upstreamable +way. It was one of the point in favor of ldap , that everything can be +easy to share. If we start to go this way, we will end like each time we +go this way, with a huge forked stuff. Packagers learned this the hard +way more than once. And lack of time + big pile of customization is what +blocked forum upgrade for years, so I really think we start to learn +from our past mistakes. + + +- openid/oauth manage the authentication ( and some vcard stuff ) but +not the autorisation. For example, Transifex ( and others django +application ) do use ldap groups for autorisation and I think that's +rather a good idea to manage this using ldap. + +While it is not the case right now for forums, as said before, there was +some discussions about having i18n/packagers/etc people having extended +rights on some subforums, this would be harder to be done cleanly +without a ldap access. + + +- moreover, keeping group of people outside of our ldap would make +various process harder. + +For example, if we want to elect moderators representatives, this would +be tedious to do it on epoll if the group is stored elsewhere ( it is +tedious now but there is some bug to fix for that ). If we want to setup +a ml synced with ldap ( like board-private@ ), this would also cause +data duplication. Email aliases are also based on ldap group membership, +etc. + + +- Most web applications will also need to access to email of users for +various reasons ( like sending email ), most will also store the email +for later usage. That's personal information that we should also protect +and I think the various threads on the subject in the past, or the +recent issue regarding Epsilon, or Google show that enough people care +about that. We cannot share them with anyone without having this written +in the privacy policy, ( policy that is still a draft cf bug 452 ) and +told to users. + + +- Moreover, if we start to give private informations to 3rd party +websites, they should IMHO also have a privacy policy, and respect it. +But yet, we cannot do much to make sure it is enforced or respected, +unless if we are root. And if we are root on the server, then I see no +reason to not handle like the others ( ie, puppet etc ). Then we are +back on the same issues that sparkled the proposal. + + +- As said on irc, there is the security issues. While we can suffer from +it on our servers too, this would be a wrong way of evaluating the risk. +If we take for example X external web sites, managed by X different +group, and the Mageia web applications, there is more attack surface +( around X+1 time more ) than just having the Mageia applications. And +unless we can guarantee that all 3rd party admins will be skilled enough +in the arcane of security, the risk would likely be bigger than smaller. + + +- I think that telling to people "it is ok to give your Mageia password +for services that are not managed by mageia.org sysadmins" is giving bad +habits. + + +- Based on my own experience with Fedora project openid provider is +this : + - 1) consumer/relaying party ask for openid provider url + - 2) provider ask for login/password + - 3) provider ask to confirm if the request is ok. + ie, confirm access to information ( such as name, email, etc ). + +Step 1 is one click to load a complete page ( ie the provider form ), +even with url hardcoded in our software. I am not sure if it doesn't +need the username ( as it is usually embedded in the url ). Point 2 is +hard to avoid, so 1 click + filling the form. Point 3 could be bypassed +automatically by patching the openid provider, but I do think users should +be in control of their personal information ( for one ) and should check +who request the information ( for 2 ), and we should not touch to openid +provider ( patching, etc ). So that would make between 3 clicks and 2 forms +to 2 clicks and 1 form. + + +- I think the service would be more difficult to scale and replicate than +ldap. For ldap, any self respecting library would work without modification, +and if not, that's a feature that would be useful to sent upstream if we +need to patch. For a stateful http service like openid, this would requires a +slightly more complex setup to be redundant, and that mean the service +would be more fragile. + + +So to summarize : +- too intrusive to deploy ( patch ) +- difficult to maintain ( non upstreamable patchs ) +- do not fully respond to some requirements +- not using ldap would cause integration problem +- suboptimal ui ( more click required ) +- potential breach of privacy +- increased security risk +- difficult to scale, more fragile + +I recognize the solution was smart and reusing a standard protocol is quite +clever, but the whole situation is more complex than just "delegating +authentication should solve the issue". + + +On the packaging side, if someone want to upload rpms, they have follow +the packaging standards to make sure we have good quality packages. +Lots of people do not like that ( see MiB, see PcLinuxOs/texstar +before ) because that requires more work and they do not see the added +values. But that doesn't mean it doesn't exist and I think that all +packagers agree that's the sanest way to do things. People are still +free to not comply, just outside of the distribution. + +For infrastructure, that's exactly the same. We do have some procedures, +with reasons and benefits to follow them, and yes, I am fairly aware +that some people would prefer it done another way. I have read what +they said, understood that having to follow some procedure is tedious, +requires more work and more time and they would prefer do it another +way. Yet, I do not think we should sacrifice integration and +maintainability because of that. + +I understand that not being root annoy some people ( I got kicked out +of Mandriva svn administration 1 week ago ), and I also guess that the +current way of doing thing is not fast enough. But I am convinced that deploying +complex and fragile system to avoid our procedures is not the way to go, or +at least, no the way I am willing to follow. + + +-- +Michael Scherer + +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="003332.html">[Mageia-sysadm] Users authentication on forums +</A></li> + <LI>Next message: <A HREF="003400.html">[Mageia-sysadm] Users authentication on forums +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#3372">[ date ]</a> + <a href="thread.html#3372">[ thread ]</a> + <a href="subject.html#3372">[ subject ]</a> + <a href="author.html#3372">[ 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> |