<div dir="ltr"><div dir="ltr">On Tue, Jul 19, 2022 at 7:41 AM Carl Schwan <<a href="mailto:carl@carlschwan.eu">carl@carlschwan.eu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">on mobile so sorry for top posting<br></blockquote><div><br></div><div>Hey Carl,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><a href="http://fund.krita.org" target="_blank">fund.krita.org</a> is using just plain oauth2 so it should be fine. Adding more auth options should also not be too hard for <a href="http://fund.krita.org" target="_blank">fund.krita.org</a> and probably a good idea in any cases.<br></blockquote><div><br></div><div>Awesome. Doesn't it also have functionality where it calls back to perform other actions (badges, etc) though?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>What I wonder though, is how you plan to do the migration. identity uses the old username has unique identifier, something we want to move away (main reasons is that people change names for various reasons). <a href="http://my.kde.org" target="_blank">my.kde.org</a> uses a uuid instead and that makes it more future proof. It is possible to use the uuid from <a href="http://my.kde.org" target="_blank">my.kde.org</a> in gitlab? I remember some big trouble with the migration (and some nasty emails) and it would be good to avoid that again.<br></blockquote><div><br></div><div><div>With regards to UUIDs, as Gitlab does not support custom fields (for users anyway) we wouldn't be able to bring MyKDE UUIDs along, however we would be able to migrate to using Gitlab User IDs - which are do uniquely identify an account and which don't change.</div></div><div>(see below API Docs)</div><div><br></div><div>Migration wise - there would be a couple of approaches utilised here depending on the site and the number of impacted people. Allowing people to associate their account on a self-service basis, email based account matching as well as some mapping that we do ourselves are all on the table.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Also did you consider using keycloak/freeIPA? These are very solid system that provides oauth2, openid connect, saml and ldap. unfortunately like we learned with mykde, oauth2 only is not really ideal, and openid connect, saml and ldap are way more standardized.<br></blockquote><div><br></div><div>Good news is that Gitlab fully supports OpenID Connect (which is really just standardised OAuth2) so we shouldn't have many issues there (see <a href="https://docs.gitlab.com/ee/integration/openid_connect_provider.html">https://docs.gitlab.com/ee/integration/openid_connect_provider.html</a>)</div><div><br></div><div>Of the applications we deploy (or have looked to deploy) I don't recall any that offered SAML as an option that didn't also offer OpenID Connect as an option so I can't imagine that would be an issue (and SAML is fairly complex so it would be ideal if we could avoid that). Given the aim to support 2FA and minimize use of credentials (particularly outside of the "home site" used for managing them), LDAP has been ruled out as a protocol we would like to support going forward.</div><div><br></div><div>With regards to Keycloak / FreeIPA, we've looked into these in the past a few times - each time ruling them out due to them being excessively complex as well as having a workflow for self-service that wasn't ideal (or was absent)</div><div>(See <a href="https://www.keycloak.org/docs/latest/server_admin/#_webauthn">https://www.keycloak.org/docs/latest/server_admin/#_webauthn</a> for some of the involved complexity)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Cheers,<br>Carl<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br><br>-------- Original Message --------<br>On Jul 18, 2022, 20:53, Ben Cooksley < <a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<blockquote><br><div dir="ltr"><div dir="ltr">On Tue, Jul 19, 2022 at 2:40 AM Halla Rempt <<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On zondag 17 juli 2022 11:54:27 CEST Ben Cooksley wrote:<br>
<br>
> I'd therefore like to move away from both Identity and MyKDE to Gitlab.<br>
<br>
What will that mean for <a href="http://fund.krita.org" rel="noreferrer" target="_blank">fund.krita.org</a>? That currently uses mykde, and that already is a problem for quite a few people to figure out how to create an account and login.<br></blockquote><div><br></div><div>The Krita Fund will need to be sorted out separately, as the Blender Fund app from which it is sourced is fairly tightly coupled with Blender ID (which is where MyKDE came from).</div><div>There is also the slight issue of it's dependence on Braintree.</div><div><br></div><div>As Ingo points out though, for user focused sites allowing a variety of login providers is likely the best path forward.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Halla<br>
<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div> </div></div></div>
</blockquote></blockquote></div></div>