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

[Buchan Milne]

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