[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication

Wed Nov 24 18:54:40 CET 2010

Hi,
+
+as proposed during previous founders meeting, we need to be clear upon
+how we want to use authentication on web applications ( and non web
+too ) with regard to ldap directory.
+
+So what I propose will apply to sympa, but could be expended on others
+applications.
+
+So the first proposal that I will expose :
+
+- users will use their personal email address and the password from ldap
+to authenticate themselves. 
+
+While this is the easiest solution ( and the current one in svn from
+what I understood ), this idea suffer from 3 issues :
+
+- people will use a different login than the one of identity. This is
+not really how a centralized login system should work, imho. And this
+was a source of confusion ( at least, of my confusion ) at Mandriva.
+
+- people will need to open a account on identity. For some applications,
+this may not be desirable. For example, on a forum, having to first
+register, and then log on the forum to fill the data is not good. For
+mailling list, if we intend to subscribe gmane, or mail archive to the
+list, this is not good either. I couldn't get in touch with rda in time,
+but I think that's what he meant ( if not, romain, feel free to correct
+me ). And in fact, this would also put more pressure on ldap than
+intended ( if we requires this for forum, we may end with a big ldap
+directory ). 
+
+- using email as login is dangerous. Since the email is freely editable
+in catdap ( and multivalued ), someone could perfectly change his email
+after opening a account, and thus get access to sympa subscription of
+someone else.  More ever, nothing guarantee that email are uniques
+across the whole DIT, especially if email span on 2 attributes ( mail
+and mailAlternateAddress ).
+
+We could however 1) check the unicity of email on ldap 2) modify catdap
+to requires a confirmation before changing anything email related.
+
+
+So then a second proposal was done :
+- users use their @mageia.org alias, and the password from ldap
+
+this one fix the 3rd issue, to be replaced by a 4th and 5th ones :
+
+- everybody who will open a account on identity will receive a alias.
+I am not sure that's what we should propose, especially since a alias is
+like a official acknowledgment. And we do not want to restrict ml to the
+few people that would receive a alias.
+
+- people will need to use the alias to post on the ml, or we will need
+to find a way to find their emails from their subscriptions. Not sure if
+sympa could do it ( but this would be great )
+
+But issue 1 and 2 still apply.
+
+
+For the sake of being complete, we could also decide to not use ldap.
+Then we would lose the centralisation of password, and that's imho
+something to avoid if we can. But that's still a option that we should
+not forget.
+
+
+So what I propose to solve this is the following scheme :
+
+A user wanting to authenticate on sympa will provide a login, who will
+be either :
+- a email ( his personal email or email of choice ) + password of his
+choice, stored by sympa, and using regular sympa authentication
+or 
+- a login ( identity login ) + password from ldap
+
+If I understood correctly, sympa support this
+( http://www.sympa.org/manual_6.1/authentication ).
+
+This way : 
+1) we do not force identity on anybody
+
+2) the login is either a email ( with email verification done by sympa,
+and email change also done by sympa ) or our fixed ldap login ( fixed,
+ie, not under the control of any user )
+
+3) people will use the same uid everywhere ( because having sometime the
+email, sometime the uid is confusing, especially if we start to offer
+email alias )
+
+So, that's the first part of my mail. 
+
+
+This issue with ldap integration will likely arise on almost every web
+application we will setup. So I would like to propose the following :
+
+we have 2 types of applications :
+- some are for use of active people
+  - submit packages, send something on svn
+  - wiki edition ( not sure on this one )
+  - transifex
+  - maintainers db
+  - etc 
+
+For those applications, we would likely require be in a team first which
+should IMHO require a account in identity.
+
+- some are for the use of the enlarged community
+  - forums
+  - mailing lists
+  - bugzilla
+  - etc
+
+Those should not requires to be in a team first, and therefore, do not
+require a account in identity. 
+
+Yet, we want to have the benefit of the central authentication as much
+as possible.
+
+So let's divide applications in 2 category :
+ 
+The one in the 1st will use ldap authentication only. That's quite easy
+to achieve most of the time. Of course, supporting ldap is not the only
+thing we want when selecting a application. Being able to support
+filter, show meaningful errors messages, and others are also to
+consider.
+
+The one in the 2nd will use some kind of hybrid auth, if possible. Ie,
+if people give a ldap login ( uid + password ), the access is granted,
+and if not, we do a fallback on some kind of native and non centralized
+login system.
+
+However this will open a can of worms :
+- what about possible login conflict, ie, how can we prevent someone
+from using "misc" ( for example ) as a login in the native users
+database ? What would happen if the conflict arise ? 
+
+Forcing people to use their email is a solution, but not everything
+support that model. We can't simply check if the login is not in use
+because someone could perfectly use it later.
+
+- what people who first open a account on the software, and later change
+to use a identity login ? How can we merge the 2 ( especially if there
+is some authorization issue ) ?
+
+This would likely requires hand edition by a admin of the DB or
+equivalent.
+
+- what about a software that do not support it, ie ldap or native, but
+not both ? Or that do not support it as we want ?
+
+So far, bugzilla support this ( ldap, and fallback on the DB ), maat
+told me this was the proposed scheme for forum ( iirc ) and that's the
+one I propose for sympa. So at least, for the example I gave, we are ok.
+
+
+and the biggest problem ( imho ) :
+
+How do we decide what category does a application belong ?
+
+Some are quite easy, and some are more difficult ( I think ). For
+example, I would be inclined to use ldap login for the wiki, or let
+people be unauthenticated. Maybe not everybody agree.
+
+What about application like mageia-app-db ? 
+This one is easier since we can specifically add this as requirement. 
+
+So to summarize :
+- can someone confirm we can do this for sympa ?
+
+- does someone see a problem with the proposed scheme for sympa, and
+does it fulfill everybody need ?
+
+- does everybody agree for the separation in 2 category of applications,
+and the consequence for the application in term of authentication ?
+
+
+-- 
+Michael Scherer
+
+