>>>>> "Stephan" == Stephan Lachnit <stephanlach...@debian.org> writes:
Stephan> On Mon, Oct 17, 2022 at 11:57 AM Bastian Blank <wa...@debian.org>
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.
