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

[Buchan Milne]

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