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

[Michael Scherer]

Le jeudi 25 novembre 2010 à 10:50 +0100, Buchan Milne a écrit :
> On Wednesday, 24 November 2010 18:54:40 Michael Scherer wrote:

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

Of course we can, but my goal was to list the various proposal that I
have understood to be proposed ( maybe they were not, but then I hope
the people who complain about me misrepresenting them will volunteer
next time :) 

For sympa, it can fetch the mail from the dn, and the dn from the login,
so we can perfectly avoid using email in login. 

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

My point is that we should be consistent. Ie, if we start using
sometimes a username, sometimes a email ( and well, I must say "one of
the numerous email people have", because I am pretty sure that I am not
the only one to have more than 1 email ), this will be annoying.

We cannot use email everywhere, since some services do not support it
( svn+ssh will not accept it, no @ in username IIRC, neither would the
current buildsystem ). And doing translation will be source of
confusion.

Morever, using email as a login would mean that it would appear at a lot
of place on the web, and that's the sort of leak that should be avoided
at least for spam prevention reason ( and because some people will
complain, and complained in the past for example on bugzilla ).

So we should use the username, as this is mean to do that.

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

That's still a 2 step procedure instead of 1. But I am not the one who
indeed would complain of that. And given that a account creation is a
rare event ( in a user timeline ), that's not a big problem.

A redirection to the service would indeed be a welcome addition. You
know what to add on the TODO list.

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

Well, the fact is managing a ldap of 400 accounts is not the same scale
to me than one of 60 000 to 1 000 000 entries. ( if I take the range of
users of Mandriva forum to the range of Ubuntu's one ). I was under the
impression that this kind of directory would requires more ressources
than what we planned. Or at least, to me, it is out of the "this will do
it without trouble" range. And since I do not remind that we did a
formal ressources planning, unless it was not widely published ( and in
this case, it should be more visible ), it seemed a lot to me.

But maybe I am worried for nothing ( since I still live in a world where
1 gb of ram is a huge amount for a server :/ ).


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

Which is not a problem, since opening a account is free. If we start to
have some private mls ( such as the one requested for forums ), reading
archive would be a privacy issue, and so step must be taken to prevent
that.

But my main point is not this particular example who is quite easy to
prevent. But rather that letting people freely edit the attribute they
use for login is IMHO a risky operation given the wide range of
application that we will have.

Editing by admin should be ok. 

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

I could see a reason :

We need to have at least 1 attribute who is the mail for which we will
forward if we set aliases ( and we will, I think we all expect them ),
who should not be multivalued. 

And we need another attribute for the email the user entered on first
login, so we know where to send a new password request.

And a 3rd attribute to handle the email in a potential vcard-like
system.

1st attribute should not be multiValued.
2nd shouldn't either.
3rd should be, but we could decide it is not.

So, my understanding is that mail is 2nd, mailAlternateAddress is the
3rd, and mailForwardingAddress is the 1st ( but a quick look at schema
do not seems to confirm this, so again, I may be wrong ).

We could reduce that to 2 attributes :
- mail act for 2 and 1, not multivalued 
- mailAlternateAdress act for 3, multivalued

or :
- mail act for 3
- mailForwardingAddress act for 1,
and we do not use anything for 2 ( like either using all mail of 3, or
just 1 ).

I would favor the first scheme.

In fact, I would even favor some system where mail mean the email people
use to receive mail for ml, and mailAlternateAdress are email that
people can use to post ( so the day I am not awake and start to use my
personal mail, I have no problem of being moderated ). But I disgress,
this has nothing to do with auth.

> > 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
> 
> ?

Ie, people can subscribe without using identity. 

Several people asked in the past to use the ml to nntp gateway of gmane.
( and to some extend some kind of forum to ml gateway )

So this require the service to subscribe to our ml. And in turn, this
mean opening a account for the service ( while before, it was able to
fully subscribe automatically at least for gmane ). So maybe there is
other popular services like there that could requires this.

We can also use the option "we do not care", or "it will just be a
little bit difficult" or "we will do it by hand", of course.

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

Sympa could support both, and that's what made me think of the dual auth
proposal ( this and the proposal of maat ). ( and Bugzilla also
supported some kind of fallback to local account ).

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

Well, some people didn't, or at least, this was my impression ( but it
seems that I was wrong ).
 
For example, IIRC, one of the few things maat told us about the forum
was the dual auth scheme ( I cannot find reference however so maybe I
dreamed ). I was also under the impression than rda didn't want people
to be in a team to subscribe on ml, which I interpreted by "people
should not open a account on ldap to subscribe on ml" ( but that was a
misunderstanding ).

So if nobody is against it, then yes, we should use ldap. 

It is more standard ( so no special knowledge, nor special changes on
anything ), more simple ( just 1 directory ), and so likely more robust
( as this already widely deployed ).

So, indeed, another proposal is :

- we use ldap for everything related to auth, and only ldap. Maybe 1
local admin password for some rare applications that requires it .

- we use username as login, and do not let user change it.

( as changing login would likely requires modification on the local
account information that every application will likely create, and
that's sound like a bad idea from a security ( ie main ldap access to
every other web app database, even if a pull system could solve this
issue ), maintainability ( hook/script to modify the data on every
impacted web applications, dependant on internal structure of the
application ) and engineering ( fragile if there is no commit/rollback )
points of view )

- we filter on team when needed



-- 
Michael Scherer