[Mageia-sysadm] Users authentication on forums

[Michael Scherer]

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 ).


> As we are using ldap for authentication only (not for groups or anything
> else), 

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 think we could do authentication differently. Maybe we could
> setup a mageia OpenID server linked to the ldap server. Then on the
> forums use OpenID for authentication, when a user enter his login on
> the forums he is redirected to the mageia OpenID authentication page
> for the login entered. Then we can disable https on the forums, and
> forum admins can be root on the forums server. And passwords are better
> protected in case phpbb has a vulnerability.

Or in case someone go rogue, or has his privileged account compromised. 

> Sysadmin team would manage openid server. And forum team would manage
> forums server.
> 
> I've seen this project for phpbb3 openid authentication (I didn't check
> if there are others) :
> http://sourceforge.net/projects/phpbb-openid/
> 
> Login form looks like this :
> http://sourceforge.net/dbimage.php?id=91989
> We would need to modify it to remove Username/Password. Replace "OpenID"
> with "Mageia login" and automatically use Mageia OpenID server with the
> login entered. So that each account on the forum is still linked to a
> Mageia account.

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