[Mageia-sysadm] Users authentication on forums

Tue Apr 26 20:24:41 CEST 2011

On Tue, 19 Apr 2011, Michael Scherer wrote:
+
+> Le lundi 11 avril 2011 à 14:39 +0200, nicolas vigier a écrit :
+> > Hello,
+> > 
+> > For authentication on the forums, we are currently using ldap. The user
+> > sends his login and passwords to phpbb which use it to authenticate on
+> > ldap server. Because of this, someone with root access on the forums
+> > server can access password of any user connecting to the forums. And
+> > because important passwords are transfered, the connection needs to be
+> > in SSL, so the *.mageia.org certificate also needs to be installed. So
+> > access to the server needs to be restricted to sysadmin team only, who
+> > also need to be able to check what is being done on forums, check it is
+> > secure, etc ... And I think this makes forums admins not happy.
+> 
+> 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 ).
+
+Yes, that's what I was thinking first. One day that I decided to be
+lazy and started to think how to get ride of forums. Maybe that is not
+a good idea. But it was planned to migrate forums to an other server
+installed and managed by other people, and we have the same problem in
+that case, that other people not in sysadmin team are root on this server.
+But even if we don't do that and continue to be the only root on the
+server, someone hacking the phpbb server could easily add a password
+logger in source code and steal passwords allowing access to svn or some
+other servers.
+
+So to avoid a security hole in one web app to give access to everything,
+I think it would be useful to separate authentication part. Actually I
+don't know enough about openid, oauth and other protocols to say which
+one is better. But we can see this with help of webteam.
+
+> 
+> - 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.
+
+I think a phpbb oauth plugin could be upstreamable. There is already an
+openid plugin, where we could add an option to force openid server, and
+maybe upstream this option.
+
+> - 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.
+
+I though it was too difficult to do it in phpbb, so we decided to not
+use ldap groups in phpbb. But using external authentication does not
+prevent us to use ldap groups. It should be possible to give limited
+ldap access to phpbb to read group infos and use something else for
+authentication.
+
+> - 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.
+
+I agree that we shouldn't store groups elsewhere.
+
+> - 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 using an authentication server is better for security :
+ - without authentication server, all web sites receive the ldap
+   password, and have read/write access to the ldap from the user
+   account. Someone taking control of one website can access all
+   passwords of users connecting.
+ - with authentication server, the web sites (except authentication
+   web site) do not receive the password, so they cannot steal it, cannot
+   authenticate on other websites. It's bad if one of the website is
+   attacked, but it doesn't give access to the svn or other websites.
+
+