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

[Michael Scherer]

Le jeudi 25 novembre 2010 à 22:40 +0100, nicolas vigier a écrit :
> On Thu, 25 Nov 2010, Michael Scherer wrote:
> 
> > > > - 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. 
> 
> To avoid this, I think email should not be freely editable in catdat,
> but should be verified first before being actually changed in ldap.
> When changing email, the user should receive on the new email an URL
> to open to confirm he is the owner of the email.


So to summarize, here is a updated proposal ( order matter ) :

- use username as primary login, not letting people change it for now.
Since most applications may not properly support it, I feel it would be
safer. 

- make sure that catdap can take username or email when resetting
password. ie :
reset password :
  - email or username :
  [send the request]  

this will likely be enough for people who forget their username, IMHO.

- make sure primary email is unique, by setting it in ldap as such.
( quite easy )

- allow to also use emails as login for all applications that support it
now. Ie username and primary email ( since it is easier to have it
unique ). Yet the username will still be the username showed, or the cn
if the application support it ( or displayName ).

Ie, even if I used michael at example.org, it would show "welcome Michael
Scherer" ( or welcome misc, if the application do not support getting
the CN or DisplayName or a custom attribute ).

So far, sympa support it. Not sure for the others.


- For those that don't, try to patch them _and_ get the patch accepted
by upstream first ( because that's already enough work to write the
patch so if it is not even accepted upstream, we will have to maintain
it and that's not good from a deployment pov ). Backporting the patch
would be ok, carrying it forever is IMHO not desirable. But theses
features seems generic enough to be a welcome addition that can be
upstreamed.

Features being "using email and/or username" and/or "showing
CN/DisplayName instead of username".



- find a way to ensure unicity of email for the secondary emails that
user can enter. If possible, on the ldap level directly, but maybe doing
it on catdap level would be enough. I would feel safer to have this at
ldap level for obvious reasons of data integrity.


- once we have enabled and checked it, and ensured that this is not a
potential source of problem, enable the use of the secondary email as a
login, in addition to username and primary email

( this should not requires much patching of application, but if needed,
same rule as previously apply ).


- ensure that aliases @mageia.org can also be used without being entered
in the ldap ( may requires some black magic at ldap level ). But if we
can't, just let people add it by themself, or add it when user get their
email aliases. 


- The username will be used by application as the "primary key" in their
local db. So people can change their email without trouble, and we will
not need to touch to the application too much when it happens. 
( or at least I hope )

Later, if we decide this is worthwhile, and if there is demand for it
( but if we let change email and display name, username may not require
change ), we have enough ressources ( because I think that would be a
issue for the moment ), we can start to check for a way of changing
username on the whole information system. 


So I think this plan of action will satisfy everybody :
- people can use their email or their username 
- people can change their emails without impacting the db, and without
requiring invasive change ( and with upstreamable patchs )
- people can change the information that is displayed, and patchs could
also be sent upstream.
- we do not have much burden of maintaining it ( as we use standard
protocols )
- we can roll out the required feature one at a time, so nothing get
late, and we have the full time to work on it and properly finish the
adaptation of others softwares

Bonus points :
- we have small patchs and features to code, so we can fill the junior
job list
- we can also communicate frequently on progress

I didn't included oauth/openid/SSO/etc in the plan, as 
- this seems much more like a much more distant goal 
- much more invasive on all levels 
- something that I still didn't grasp 


So, is everybody ok with this plan ?

-- 
Michael Scherer