If we get rid of pad.libreho.st, then we’ll have 2 tools left that needs sso: lab and talk.
I personally can’t commit to maintain it.
I find it a beautiful idea to have this sso federation, but I’m also fine to have 1 more password to save in my password manager.
If nobody commit to maintain it or come up with a solution by the next meeting, I propose to shut it down.
If we shutdown lab and pad, we’re left with a single service, so SSO is not particularly useful.
As suggested during last meeting, it could be nice to share an SSO among librehosters, but if this option is not pursued, so be it.
I’d still be interested in the actual setup on my side to be able to share my SSO with LH SSO (@matronix’s setup), whatever the fate of this service. Some of us might still want to share services even if we don’t have a collective SSO.
That said, maintaining a basic keycloak is not so complicated so it might be useful to keep it running since everybody has been using it so far to connect to the services ; additionally, if we’re moving the repositories to another Gitlab, it would be useful to maintain connectivity from our existing infrastructure to the target Gitlab, so that the move is seamless to the users and they can still have correct group and individual accesses to repositories.
IH also proposed that the LH SSO would become a realm in their own Keycloak. This could be a good solution as well, especially if the lab is moving to their infra, and the connection is then easier to make.
Adding: I may have thought about a situation where it would be preferable to maintain a SSO under the libreho.st banner, namely, data portability. Imagine a member (or customer) of one of the librehosters. They have an account, say at indie.host. They want to use a service from another librehoster, maybe a WireGuard tunnel from Disroot.org. Then they could use the LH SSO to access to their VPN panel at Disroot.
In fact, the more I think about it, the more I find Keycloak (or the SSO in general) a very good way to collaborate. We could have hoster-specific Identity Providers (e.g., a clustered Keycloak installation per Librehoster, or similar/compatible setup) forming a cross-datacenter replicated SSO that would serve as high-availability SSO and cross-ISP service, helping both sysadmins and users to move seamlessly from one host to another depending on their preferences and needs.
That said, I can foresee the technical burden to keep this up while we were not able to coordinate over the last year. I’d rather keep this in mind (and keep LH SSO up in the meantime) and concentrate on sharing other more critical services such as backups.
We as Ecobytes would also love to join that federation, once we learn how to do so.
Is there a separate conversation where we sketch, design and discuss this idea? Because I like it, and because we all might have suitable backup targets through Borg setups, S3 endpoints and, for us and others who like it, ZFS. We’re even considering storing raw ZFS snapshot replication streams into S3, but that’s again another subject.
/cc @gandhiano
Feel free to start a topic on backups.