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

Fri Nov 26 01:47:52 CET 2010

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