[Alioth-staff-replacement] Alioth needs your help
Geert Stappers
stappers at stappers.nl
Sun Aug 20 12:57:26 UTC 2017
On Sun, Aug 20, 2017 at 02:39:36PM +0200, Alexander Wirt wrote:
> On Sun, 20 Aug 2017, Shengjing Zhu wrote:
> > On Sun, Aug 20, 2017 at 7:47 PM, Mattia Rizzolo <mattia at debian.org> wrote:
> > > I wonder: would it be so complex to have gitlab use sso.d.o for
> > > authentication? Consider that sso.d.o only provides with user
> > > certificates, doesn't have any openid/oauth2/whatever provider.
> > >
> > > sso.d.o could grow a registration feature for guest accounts (instead of
> > > pulling them from alioth, I can't see that as something so different).
> > >
> >
> > It would be great if sso.d.o provides oauth2.
> > And has a independent account system for guests, considering after Alioth
> > retired, there should be a way for guests to access.
> >
> > And I think it still needs a shim for gitlab to integrate with
> > sso.d.o, and restrict
> > the account name.
> > For example, someone login to a registery service via sso.d.o,
URL to sso.d.o. is https://sso.debian.org/
> > and that service creates account on gitlab with proper name.
> > Or better, we write a ruby plugin that makes gitlab talk to sso.d.o directly.
> > After a quick look at gitlab docs, it can be achieved by writing a omniauth[1]
> > plugin
> it will probably the other way round. Gitlab as being a backend for sso.
That feels wrong.
> SSO doesn't have own backends.
Isn't db.debian.org the backend that knowns about all DD?
Groeten
Geert Stappers
--
Leven en laten leven
More information about the Alioth-staff-replacement
mailing list