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

Thu Nov 25 10:50:44 CET 2010

On Wednesday, 24 November 2010 18:54:40 Michael Scherer wrote:
+> 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.
+
+Is this a limitation in sympa? All LDAP-capable software should allow 
+configuration of which attribute to authenticate against ...
+
+> 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.
+
+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.
+
+> 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.
+
+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.
+
+> 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 ).
+
+AFAIK, the forum only impacts LDAP on login to the forum, not on every page 
+view etc.
+
+> - 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.
+
+And lose their account to the user whose email address was used as soon as we 
+allow user-initiated password reset ...
+
+> More ever, nothing guarantee that email are uniques
+> across the whole DIT, especially if email span on 2 attributes ( mail
+> and mailAlternateAddress ).
+
+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.
+
+> 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.
+
+Let's have a policy on aliases before we make decisions that require or 
+prevent them ...
+
+> - 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 )
+
+We need to chose one ...
+
+> 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 )
+
+I had assumed this would be the strategy from the beginning.
+
+> 
+> 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.
+
+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).
+
+> 
+> - 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.
+
+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 ...
+
+> 
+> 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.
+
+IMHO, this is more trouble than it is worth, and more trouble than having all 
+users on LDAP.
+
+> 
+> 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.
+
+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.
+
+> - 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 ?
+
+We file bugs, supply patches, or choose other software that is suitable.
+
+> 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 ?
+
+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).
+
+> 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.
+
+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 
+
+> 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 ?
+
+Which proposed scheme? Using uid as username?
+
+> - does everybody agree for the separation in 2 category of applications,
+> and the consequence for the application in term of authentication ?
+
+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
+