[Mageia-sysadm] Users authentication on forums

[Buchan Milne]

----- Original Message -----
> 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"

But, the first question is, how do people know what services are managed by mageia.org sysadmins (regardless of how they are authenticated).

IMHO, services supported by mageia.org sysadmins should be on a mageia.org hostname, services that are not, should *not* be, or should otherwise be separately identified. So, if the forum is not going to be managed by mageia.org sysadmins, and we can't give assurances that a privacy policy is adhered to, etc. etc., then IMHO, it should not be hosted on forums.mageia.org, but maybe forums.mageia-community.org or similar.

> OpenID/OAuth are precisely designed to avoid this.

Well, are designed to avoid users entering credentials into multiple sites/services. But, the confidentiality of the data that the user subsequently provides to the service is not addressed (although to some extent, data that the 2nd party - the authorizing service - provides to the 3rd is).

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

>From the start, the intention was to be able provide an OpenID provider on mageia.org, authenticating against LDAP. so that contributors could use their mageia identity on other open-source platforms.

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

My plan was to use something like https://identity.mageia.org/openid as an OpenID provider, using some of the existing Perl modules that provide some OpenID support (e.g. http://search.cpan.org/~lyokato/OpenID-Lite-0.01_04/lib/OpenID/Lite/Provider.pm), but unfortunately I have 1)been a bit busy with a new baby in the house, 2)very limited bandwidth at home, 3)new responsibilities at work.

If someone else has some more experience with OpenID and/or OAuth, and can give some pointers, that may help.

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

Sure.

> - possibly setup and implemented/provided by non sysadmins

Tested/written by non sysadmins, sure, setup, no, as the software will need some more privileged access to LDAP that most user accounts.

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

Well, even though some pieces took a while to get into place, I think we have managed to provide an adequate experience to users, and been able to encourage a lot of contributors to have accounts which can be used for a number of services. But, until now, most services have had LDAP support, and many of them needed to run on our infrastructure.

This by no means means that this is all we should or are willing to support, but there is a bit more work left to provide more modular authentication.

Regards,
Buchan