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

Romain d'Alverny rdalverny at gmail.com
Wed Nov 24 20:29:04 CET 2010


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

Exceptions come later.
 * the same way: email/password
 * a single directory: LDAP (no local app user account unless it is
admin/setup specific or the application integration is really
separate)
 * exceptions: when the application integration/workflow commands it
(buildsystem access with login? sympa?)
 * exceptions may be handled locally (they ask for login/password) or
through an API (instead of calling LDAP, they call a specific
webservice passing email/password, which service replies the login and
local app uses returned values).

(apart from the LDAP bit that was replaced by a MySQL db + web
services, all of this was implemented at Mandriva, although not to a
fully satisfying point)

In my view, apps that qualify for this generic rule  (ldap only +
local fallback for admin):
 * bugzilla
 * forum
 * wiki
 * actually, any webapps you could think of, provided you can make a
ldap query from it

That qualify for the login exception:
 * svn/git/etc. (not sure but I guess so)
 * other?


#2. Consequences

That means that identity should authenticate with email preferably
(but may allow using the login).

That does not prevent that local app data is locally stored. 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.

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


#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 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)
 * 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)).

I don't think we should provide @mageia.org email at large, for the
same arguments as misc's.




The view I exposed above adds contraints, but has several benefits:
 * a single/consistent repository/auth mechanism for all users and for all apps
 * it forces apps to manage all user accounts the same way (will help
for mashing up their data and making it possible to them to manage
them in a consistent way); we can define levels of features for apps
about this;
 * users get a more complete profile upon their roles within the project

Cheers,

Romain

On Wed, Nov 24, 2010 at 18:54, Michael Scherer <misc at zarb.org> wrote:
> [...]
> 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 ?
>
> - does everybody agree for the separation in 2 category of applications,
> and the consequence for the application in term of authentication ?


More information about the Mageia-sysadm mailing list