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

Thu Nov 25 11:22:50 CET 2010

On Wednesday, 24 November 2010 20:29:04 Romain d'Alverny wrote:
+> Hi,
+> 
+> thanks for the long description. Instead of replying point by point, I
+> would like to suggest a more radical point of view, that actually
+> determined the my.mandriva setup (that would not make a difference
+> between "regular" users and "active" users from a auth/storage POV). I
+> think it's worth it to discuss it as well.
+> 
+> The rationale is to ease the user flow through the project, as a
+> whole. 4 points below.
+> 
+> #1. General rule: all users authenticate the same way against a single
+> directory
+
+IMHO this is non-negotiable.
+
+> #2. Consequences
+> 
+> That means that identity should authenticate with email preferably
+> (but may allow using the login).
+
+Most applications can be configured to authenticate on any LDAP attribute. 
+This is more of a policy/usability issue than a technical one.
+
+> That does not prevent that local app data is locally stored.
+
+Only non-application-specific should be in the directory. Application-specific 
+user data stays in the application.
+
+> That's
+> how my.mandriva scheme was designed (and could have gone further).
+> That does not prevent that local apps provide a way for the user to
+> build a mashup of all data around (for a reporting/activity/social net
+> app for instance).
+> 
+> That means that any user using any part of the Mageia infrastructure
+> has to get an account through identity.mageia.org. And that
+> email/login must be tested for unicity.
+
+At present we are only using uid for login, which is unique-enforced (as it is 
+the RDN).
+
+> That also puts some constraints on how an app manages authentication
+> and local user data:
+>  * it must be able to authenticate from an outside source
+>  * it must be able to manage primary email change (we used a
+> "customer_id" at Mandriva, a 64 char id that allowed to change both
+> email and login at will without losing user reference; would that
+> match the uid?)
+
+It would be possible to rename the user account, but most applications will be 
+using the "login" as the key to store preferences. LDAP has entryUUID to allow 
+tracking of entries across renames, but ... most application supporting LDAP 
+authentication will use the login name for keying user information. Getting 
+applications to use a different attribute for this is more of a challenge.
+
+How important is it to be able to allow changes to the 'login'?
+
+(Of course, this motivates against using email address as login).
+
+>  * it must be able to update, if needed, locally cached data that
+> source from the central repository.
+> 
+> To some extent, it could even have the ability to manage a central
+> session server, but that may be left for a later time (and can
+> actually be managed almost separately once the central auth is done).
+> 
+> (we may use OAuth and OpenID auth at a later time for web apps. That
+> shouldn't have an impact on the above (and below) authentication
+> scheme anyway)
+> 
+> So what about apps that do not support this scheme? We patch them so
+> they do (and we do it the clean way). Puts more constraints on the
+> dev/admin side, for sure; but again, the rationale is to provide a
+> consistent interface to the user with easiest to remember items (email
+> then, instead of login). And that forces us to find a consistent
+> protocol that is already (or should be) implemented in our apps.
+
+Cost/benefit for supporting login changes?
+
+> #3. Sympa
+> 
+> As for sympa, that's a particular exception in that it uses the same
+> email address as an identity token and as an contact address (or could
+> it authenticate against a primary email address and use a second one,
+> returned by the directory, to post mails to? requires sync from time
+> to time). It is tricky (but no unfeasible I guess, it just asks the
+> problem to be properly laid out) and I would leave the sympa setup
+> separate at first, with the possibility to later make a soft link
+> between a LDAP account (being able to ask sympa "for this email, what
+> do you have?") and experiment safely with a proper integration. This
+> just to move forward withouth putting too long a delay on production
+> release. That would mean, at first, let people authenticate/subscribe
+> on Sympa using only local Sympa db.
+> 
+> 
+> #4. Email as an id
+> 
+> As to objections on using the email as an id:
+>  * I didn't mean that forum should use local accounts instead of LDAP
+> ones, the contrary actually; what it takes is that the account
+> registration procedure must be routed to identity, instead of the
+> regular forum process; and that the forum auth mechanism must handle
+> on-the-fly creation of a local account from a valid LDAP account;
+
+I logged in to the test forum setup with only my account in LDAP, without 
+problems. So, only username/password aspects (registration, password change, 
+password reset) must be redirect to identity. Bugzilla is already configured 
+to reject password change or registration, with a message to visit 
+identity.mageia.org.
+
+>  * I am not sure to see the issue with gmane/mail archive?
+>  * if having a big LDAP is an issue (why would it be?) then LDAP is
+> not the solution for a central auth directory (and that would be
+> ironic somehow)
+
+Uh, we agreed earlier that we would have at least one slave, which would be 
+used for internet-facing stuff, and at least one directory server (e.g. 
+master) which is not used for internet-facing stuff, to ensure admin access 
+works even in the case of a DoS.
+
+>  * using email as a login, we obviously must have emails editable
+> separately in LDAP, test their unicity within their own scope (being a
+> primary email, or a secondary one is not the same), should have a
+> validity status from one (that is, making sure someone ends up reading
+> a message posted to it).
+>  * when we decided to use the email as the id for Mandriva web
+> services, the biggest problem that arose in the end was: would it work
+> for authenticated HTTP urls, like:
+> https://user@domain.tld:password@server.domain.tld/ (so it would work
+> for private downloads)? It does (wget does it; curl has hiccups about
+> it that can be easily worked out (escape the first @ or parse the url
+> to provide ids as arguments)).
+
+Consider though using a modifiable attribute as the key for storing all other 
+applications configuration.
+
+> I don't think we should provide @mageia.org email at large, for the
+> same arguments as misc's.
+
+This is an issue unrelated to LDAP and what attribute to use for 
+authentication IMHO, but has implications for LDAP (alias maps etc.).
+
+Regards,
+Buchan
+