Re: Sunsetting sso.debian.org
On Tue, Oct 18, 2022 at 11:20:10AM +0200, Joerg Jaspert wrote: > Am 2022-10-18 04:52, schrieb Paul Wise: > > > Salsa should be there for git (related) things. > > > NOT as an identity/login provider for Debian Please formally retract the agreement that was forged two years ago then. I properly referenced it already. Until then, it still is an identity provider. > No, it is a bad, not a good thing, to use Salsa for this. > Salsa is a "repository service" with some added nice features related to > them. It is good at that, yay. Fine. No, it is much more then a repository system. > Salsa is really bad as an identity/authentication service. Having a salsa > account does NOT mean ANYTHING related to Debian, like DM/DD/whatever. It is an identity provider, yes. It provides a fixed identity. Further information are optional. Where are they required? >And > thats information that such a service ought to provide too. This is the Debian LDAP. > It also does not > allow any kind of useful management of identities besides "the account is > there/blocked/deleted". And so, as soon as you would want to NOT allow > someone a login to a service that uses salsa as a login service - you need > to delete their account. Including their repositories and abilities there. > Not good. When exactly do you want to do that and how would that work? Bastian -- Women are more easily and more deeply terrified ... generating more sheer horror than the male of the species. -- Spock, "Wolf in the Fold", stardate 3615.4
Re: Sunsetting sso.debian.org
Am 2022-10-18 04:52, schrieb Paul Wise: Salsa should be there for git (related) things. NOT as an identity/login provider for Debian There are already Debian services that do not offer any other option for auth than Salsa. Which is bad. And should be changed. Arguably it is probably a good thing to use Salsa, since it means services can have an auth option for all of the Debian contributors, including those who are not currently DDs or DMs. No, it is a bad, not a good thing, to use Salsa for this. Salsa is a "repository service" with some added nice features related to them. It is good at that, yay. Fine. Salsa is really bad as an identity/authentication service. Having a salsa account does NOT mean ANYTHING related to Debian, like DM/DD/whatever. And thats information that such a service ought to provide too. It also does not allow any kind of useful management of identities besides "the account is there/blocked/deleted". And so, as soon as you would want to NOT allow someone a login to a service that uses salsa as a login service - you need to delete their account. Including their repositories and abilities there. Not good. IMO that functionality of salsa should be deactivated *right* *now*. To not have it get used even more. Salsa ought to use some service for login, not the other way. Keycloak or whatever else, doesnt matter. And that service ought to be properly integrated with NM and the DSA services. -- bye Joerg
Re: Sunsetting sso.debian.org
On Mon, Oct 17, 2022 at 5:29 PM Sam Hartman wrote: > > I think the minimal solution here, which I'm not volunteering to do, is > for tracker.debian.org to gain salsa sso support instead of client cert > support. Can point out the tracker.d.o code? Maybe I'll take a look, I find this topic interesting (but I can't promising anything - short on time and never done stuff like this before). On Tue, Oct 18, 2022 at 4:53 AM Paul Wise wrote: > > On Mon, 2022-10-17 at 21:28 +0200, Joerg Jaspert wrote: > > > Salsa should be there for git (related) things. > > NOT as an identity/login provider for Debian > > There are already Debian services that do not offer any other option > for auth than Salsa. > > Personally I do not like GitLab, Salsa nor OIDC/Oauth2, vastly prefer > TLS client certs and thus usually never use Salsa authed services. > > Arguably it is probably a good thing to use Salsa, since it means > services can have an auth option for all of the Debian contributors, > including those who are not currently DDs or DMs. I think this more an argument against Salsa than one for it - just having a Salsa account does not really put you into any "box" except whether you are part of the Debian group or not. Having a "proper" SSO that connects to db.d.o and has proper groups such as DD, non-uploading DD, DM, etc is not a bad idea. Again, not saying that it is worth the effort. On Mon, Oct 17, 2022 at 2:04 PM Yadd wrote: > > Also lemonldap-ng, already packaged Cool, didn't know that one, thanks for pointing out. Do you by any chance know whether it supports client certs or not? Since it seems there are ppl prefering client certs, it would be nice to have an option that supports both.
Re: Sunsetting sso.debian.org
On Mon, 2022-10-17 at 21:28 +0200, Joerg Jaspert wrote: > Salsa should be there for git (related) things. > NOT as an identity/login provider for Debian There are already Debian services that do not offer any other option for auth than Salsa. Personally I do not like GitLab, Salsa nor OIDC/Oauth2, vastly prefer TLS client certs and thus usually never use Salsa authed services. Arguably it is probably a good thing to use Salsa, since it means services can have an auth option for all of the Debian contributors, including those who are not currently DDs or DMs. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Sunsetting sso.debian.org
On 17.10.22 17:29, Sam Hartman wrote: That * Gives us a second source of sso * still leaves tracker wanting to consume client certs * As far as I can tell keycloak can consume but not produce client certs * Even if it can produce client certs we have all the usability challenges of client certs But is there a technical reason for tracker.d.o to do client certs in the first place? It's easy for a first-party d.o service running on DSA machines to enable OpenID Connect-based SSO against Salsa. And that only requires minor changes to the code to get the username from the slightly different HTTP header. If there are API clients talking to it, it might be slightly more involving to setup - but it's not like other people haven't had to deal with getting OIDC tokens for various APIs before. :) Kind regards Philipp Kern
Re: Sunsetting sso.debian.org
On 16654 March 1977, Sam Hartman wrote: I think the minimal solution here, which I'm not volunteering to do, is for tracker.debian.org to gain salsa sso support instead of client cert support. But that isnt neccessarily the best solution. I think it would be better to NOT rely on salsa for SSO. Salsa should be there for git (related) things. NOT as an identity/login provider for Debian, that is a different task. -- bye, Joerg
Re: Sunsetting sso.debian.org
> "Stephan" == Stephan Lachnit writes: Stephan> On Mon, Oct 17, 2022 at 11:57 AM Bastian Blank wrote: >> >> Everyone coming up with solutions, please review the old thread >> about that >> https://lists.debian.org/msgid-search/20200405184610.ga581...@waldi.eu.org Stephan> Keycloak also provides OpenID Connect / OAuth2 and can Stephan> connect to LDAP servers - so it is not really "intrusive" Stephan> in that sense. For websites using the SSO the switch would Stephan> probably just changing a URL, which of course opens the Stephan> question what the advantage of Keycloak over the current Stephan> Gitlab based solution would be. I guess Keycloak integrates Stephan> better to LDAP and has more user management tools, but that Stephan> doesn't mean the work is worth it. I just wanted to point Stephan> out a solution in case we want a new SSO. Okay, that's all great and stuff, but I'm not sure it solves the problem we have. Today, we have: * Some services using salsa for sso * tracker using client certs * The source of client certs going away unless someone steps up to maintain it. * Like enrico, I think sso.debian.org's time has passed, and I don't think stepping up to keep it alive advances anything. You propose adding keycloak. That * Gives us a second source of sso * still leaves tracker wanting to consume client certs * As far as I can tell keycloak can consume but not produce client certs * Even if it can produce client certs we have all the usability challenges of client certs I think the minimal solution here, which I'm not volunteering to do, is for tracker.debian.org to gain salsa sso support instead of client cert support.
Re: Sunsetting sso.debian.org
Le 17 octobre 2022 13:50:36 GMT+02:00, Stephan Lachnit a écrit : >On Mon, Oct 17, 2022 at 11:57 AM Bastian Blank wrote: >> >> Everyone coming up with solutions, please review the old thread about >> that >> https://lists.debian.org/msgid-search/20200405184610.ga581...@waldi.eu.org > >Keycloak also provides OpenID Connect / OAuth2 and can connect to LDAP >servers - so it is not really "intrusive" in that sense. For websites >using the SSO the switch would probably just changing a URL, which of >course opens the question what the advantage of Keycloak over the >current Gitlab based solution would be. I guess Keycloak integrates >better to LDAP and has more user management tools, but that doesn't >mean the work is worth it. I just wanted to point out a solution in >case we want a new SSO. > >Cheers, >Stephan Hi, Also lemonldap-ng, already packaged Cheers, Yadd -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Sunsetting sso.debian.org
On Mon, Oct 17, 2022 at 11:57 AM Bastian Blank wrote: > > Everyone coming up with solutions, please review the old thread about > that > https://lists.debian.org/msgid-search/20200405184610.ga581...@waldi.eu.org Keycloak also provides OpenID Connect / OAuth2 and can connect to LDAP servers - so it is not really "intrusive" in that sense. For websites using the SSO the switch would probably just changing a URL, which of course opens the question what the advantage of Keycloak over the current Gitlab based solution would be. I guess Keycloak integrates better to LDAP and has more user management tools, but that doesn't mean the work is worth it. I just wanted to point out a solution in case we want a new SSO. Cheers, Stephan
Re: Sunsetting sso.debian.org
On Sun, Oct 16, 2022 at 07:22:28PM +0200, Enrico Zini wrote: > I'm posting this to debian-devel as an early heads-up and a call for > other maintainers. If nobody steps in my the end of October, I'll post a > proper sunset announce to debian-devel-announce. Everyone coming up with solutions, please review the old thread about that https://lists.debian.org/msgid-search/20200405184610.ga581...@waldi.eu.org Regards, Bastian -- What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, "Metamorphosis", stardate 3219.8
Re: Sunsetting sso.debian.org
Hi, On Mon, 17 Oct 2022, at 09:52, Hakan Bayındır wrote: > We use Keycloak in both at office and in international projects as > backbones of relatively big and federated SSO systems, and it works fine. > > It's not very hard to deploy and configure on bare metal. Enabling its > own HTTPS/SSL features are also relatively straightforward. > > I'm sure that it can handle a project at the size of Debian. It handles > traffic from half of EU (as a part of EGI SSO infrastructure) just fine. We use Keycloak recently at Collabora, and it does its job well. We’ve only started using it recently, so it’s not being used up to its full potential, I guess, but from what I was told by people who worked with it closely there weren’t any issues, and it doesn’t seem resource-hungry. -- Cheers, Andrej
Re: Sunsetting sso.debian.org
We use Keycloak in both at office and in international projects as backbones of relatively big and federated SSO systems, and it works fine. It's not very hard to deploy and configure on bare metal. Enabling its own HTTPS/SSL features are also relatively straightforward. I'm sure that it can handle a project at the size of Debian. It handles traffic from half of EU (as a part of EGI SSO infrastructure) just fine. Cheers, Hakan On 17.10.2022 10:14, Stephan Lachnit wrote: On Sun, Oct 16, 2022 at 7:23 PM Enrico Zini wrote: I would welcome better single sign-on systems for Debian than Salsa, and sso.debian.org is not it. I think Keycloak [1] is quite nice and used more and more by other FOSS projects (it is RedHat sponsored after all). Opinions about using this as potential SSO? Can be easily integrated to Salsa/Gitlab as well (packaging might not be easy though). Cheers, Stephan [1]: https://www.keycloak.org/ OpenPGP_signature Description: OpenPGP digital signature
Re: Sunsetting sso.debian.org
On Sun, Oct 16, 2022 at 7:23 PM Enrico Zini wrote: > > I would welcome better single sign-on systems for Debian than Salsa, and > sso.debian.org is not it. I think Keycloak [1] is quite nice and used more and more by other FOSS projects (it is RedHat sponsored after all). Opinions about using this as potential SSO? Can be easily integrated to Salsa/Gitlab as well (packaging might not be easy though). Cheers, Stephan [1]: https://www.keycloak.org/
Re: Sunsetting sso.debian.org
On Sun, 2022-10-16 at 16:21 -0700, Sean Whitton wrote: > At the present time, I believe this will break DDs logging into > tracker.debian.org. I recently had to mess around with client > certificates in order to login there and subscribe to a new package. It will still be possible to manage DPT subscriptions via email: https://www.debian.org/doc/manuals/developers-reference/resources.en.html#the-debian-package-tracker https://qa.pages.debian.net/distro-tracker/usage/messages.html#subscribing-to-a-package In addition it will still be possible to subscribe via the web using the form at the bottom left of the pages on the old PTS, IIRC this will send mail to modify the DPT subscriptions. https://packages.qa.debian.org/z/zlib.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Sunsetting sso.debian.org
Hello, On Sun 16 Oct 2022 at 07:22PM +02, Enrico Zini wrote: > Hello, > > I've just fixed sso.debian.org to work again after the upgrade of > diabelli to bullseye. > > I however have not used SSO certificates in years and don't intend to. > This means I'm unable to test if certificate authentication still works, > and to effectively maintain the site: I won't be able to do much more to > it than fix Django issues. > > Unless some other DD steps in to take over maintenance, I annouce my > intention to decommission sso.debian.org by the end of March 2023. > > I would welcome better single sign-on systems for Debian than Salsa, and > sso.debian.org is not it. > > I'm posting this to debian-devel as an early heads-up and a call for > other maintainers. If nobody steps in my the end of October, I'll post a > proper sunset announce to debian-devel-announce. Thank you for the notification. At the present time, I believe this will break DDs logging into tracker.debian.org. I recently had to mess around with client certificates in order to login there and subscribe to a new package. -- Sean Whitton
Sunsetting sso.debian.org
Hello, I've just fixed sso.debian.org to work again after the upgrade of diabelli to bullseye. I however have not used SSO certificates in years and don't intend to. This means I'm unable to test if certificate authentication still works, and to effectively maintain the site: I won't be able to do much more to it than fix Django issues. Unless some other DD steps in to take over maintenance, I annouce my intention to decommission sso.debian.org by the end of March 2023. I would welcome better single sign-on systems for Debian than Salsa, and sso.debian.org is not it. I'm posting this to debian-devel as an early heads-up and a call for other maintainers. If nobody steps in my the end of October, I'll post a proper sunset announce to debian-devel-announce. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
