[Mageia-sysadm] Users authentication on forums

[Romain d'Alverny]

Hi there,

a small update because I was not convinced - and waiting for beta2 was
a good time. :-p

On Tue, Apr 19, 2011 at 01:10, Michael Scherer <misc at zarb.org> wrote:
> - openid/oauth manage the authentication ( and some vcard stuff ) but
> not the autorisation. For example, Transifex ( and others django
> application ) do use ldap groups for autorisation and I think that's
> rather a good idea to manage this using ldap.

OAuth is about authorizing a 3rd party application to get access to a
set of credentials (on user acceptance) - that could include groups.
And many other things. So that's still up to your local app to use
that for authorization.

> - I think that telling to people "it is ok to give your Mageia password
> for services that are not managed by mageia.org sysadmins"

OpenID/OAuth are precisely designed to avoid this.

> I recognize the solution was smart and reusing a standard protocol is quite
> clever, but the whole situation is more complex than just "delegating
> authentication should solve the issue".

It's not about delegating authentication, that stays on mageia.org servers.

I understand your point too. Anyway. Let's see it again from a
different perspective now. No offense intended to anyone, but just
stating it plain.

Choosing this current scheme (LDAP + Perl-based Web frontend + strict
policy on authentication/authorization scheme) makes it:
 - something completely centralised where, when someone could
add/extend an application to the Mageia ecosystem, it has to ask for
permission first (LDAP app-specific credentials, app hosting control),
instead of just using a piece of infrastructure that would enable
users to use it (OAuth + open APIs) and giving their permission - and
keeping control of it; I am not saying that Web developers are craving
to do that at once, but preventing this sort of thing from happening
doesn't help;
 - discussions about improvements cut down for the sake of not
patching pieces of code, making the whole thing so generic, that it
will stay generic (genericity is good, but not at the price of not
progressing/making new stuff).

We can either decide to stay like this - but I'm not sure to see the
point because it doesn't scale - beyond that it's not really
interesting either. Yes, the sysadmin team is not extensible and would
welcome hands to help - showing too conservative a status will not
help either.

Or decide that we need to open and let go a bit more and design all
our services in a more modular/flexible way, yet secure. And if
needed, ask for help on the outside, among people that would be
willing to help (not only volunteers, but companies whose interest
could align with dedicating some employees time with the project). For
instance, continuing as it is today, but accepting to set up an OAuth
provider service in a given perimeter, plugging it in LDAP with the
auth part still in mageia.org, and see how things go from there?

Note that I'm not arguing against the team or anyone here, but for a
different take on how some services may be provided in a more flexible
way. :-) I'm sure a set of beers and a whiteboard would help a lot
here but all we have for now is this text-based thing.

(that's not a binary switch - I discussed with some of af83 engineers
about one of their project they demonstrated at WebWorkersCamp past
week-end (https://github.com/AF83/auth_server ) - and it seems they
would be happy to help with this - that's in part why I suggest a bit
more about this)

So the question, to sum it up is this: would the sysadmin team be ok with:
 - experimenting such an authorization gateway (as oauth2 here) that
would allow other apps to use Mageia user accounts for
authentication/authorization;
 - possibly setup and implemented/provided by non sysadmins

It's not about setting a fight between systems integrity/admin and
foolish experiments/developments - it's about allowing ideas to bubble
through the project without too many obstacles in the middle.

No hurry either, better make sure everyone is on par on this.


Cheers,

Romain