Future of Web Single Sign On in KDE

[Ben Cooksley]

On Tue, Jul 19, 2022 at 7:41 AM Carl Schwan <carl at carlschwan.eu> wrote:

> on mobile so sorry for top posting
>

Hey Carl,


>
> fund.krita.org is using just plain oauth2 so it should be fine. Adding
> more auth options should also not be too hard for fund.krita.org and
> probably a good idea in any cases.
>

Awesome. Doesn't it also have functionality where it calls back to perform
other actions (badges, etc) though?


>
> 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). my.kde.org
> uses a uuid instead and that makes it more future proof. It is possible to
> use the uuid from my.kde.org in gitlab? I remember some big trouble with
> the migration (and some nasty emails) and it would be good to avoid that
> again.
>

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.
(see below API Docs)

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.


>
> 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.
>

Good news is that Gitlab fully supports OpenID Connect (which is really
just standardised OAuth2) so we shouldn't have many issues there (see
https://docs.gitlab.com/ee/integration/openid_connect_provider.html)

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.

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)
(See https://www.keycloak.org/docs/latest/server_admin/#_webauthn for some
of the involved complexity)


>
> Cheers,
> Carl
>

Cheers,
Ben


>
>
>
> -------- Original Message --------
> On Jul 18, 2022, 20:53, Ben Cooksley < bcooksley at kde.org> wrote:
>
>
> On Tue, Jul 19, 2022 at 2:40 AM Halla Rempt <boud at valdyas.org> wrote:
>
>> On zondag 17 juli 2022 11:54:27 CEST Ben Cooksley wrote:
>>
>> > I'd therefore like to move away from both Identity and MyKDE to Gitlab.
>>
>> What will that mean for fund.krita.org? 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.
>>
>
> 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).
> There is also the slight issue of it's dependence on Braintree.
>
> As Ingo points out though, for user focused sites allowing a variety of
> login providers is likely the best path forward.
>
>
>> Halla
>>
>>
> Cheers,
> Ben
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20220719/85ed69f6/attachment.htm>