Future of Web Single Sign On in KDE

[Ben Cooksley]

Hi Community,

Over the past few months, I've been contemplating what we need from an
Identity replacement to meet the needs of our web services both now and
into the future - especially given the current condition of Identity.

This also involves evaluating whether this is something that truly needs to
be completely custom - or whether it can be something off the shelf.

As it is modern security best practice to not get people comfortable with
logging in using their credentials on any site, the new service must be
able to support this practice - with OAuth2 being the best placed in a
modern context to do so.

The list of requirements that results from this is:
- User profiles that contain a name and email address(es)
- Groups that users belong to, with the possibility of delegating
management to non-Sysadmins
- Support for strong 2FA methods (TOTP at a minimum, with U2F/FIDO2 being
preferred)
- Support for 'application passwords' to allow us to support systems that
cannot handle OAuth2 based authentication (such as SMTP)

On investigation most systems that are dedicated "identity providers" are
both very heavy, complex and don't meet our needs very well (usually
lacking self-service registration and password reset systems, as they're
designed for corporate use).
While they do tend to support other protocols for Identity Federation as
well (like SAML) those aren't necessary for our purposes and simply create
additional security risk.

We are already running a very capable and well supported bit of software
that can act as an OAuth2 provider (and ticks all the other above boxes)
and has pre-existing support available for most of the web software we run
though - Gitlab.

Given that reinventing the wheel is both expensive and risky (requiring
volunteer time to maintain, requiring us to keep on top of any security
issues in the underlying stack ourselves, etc) i'm very much in favour of
using something 'off the shelf'.
Additionally some of the software we may want to use in the future is very
likely to want to talk to Gitlab (to interact with issues, commit to
repositories on behalf of users, etc) which requires that application to
interface with Gitlab directly anyway.

I'd therefore like to move away from both Identity and MyKDE to Gitlab.

Because we are already populating most group information, as well as names
and email addresses in Gitlab the 'migration' of data part of the equation
is mostly completed already. When we finally 'cut the cord' and shutdown
Identity people would need to perform a password reset to regain access but
that would be the only point of pain. Those people who haven't logged into
Gitlab by the point we 'cut the cord' would have their information deleted
(unless they hold a Developer account or are an e.V. member in which case
we would provision an account for them with their data) as the information
would be considered to be information that is no longer required.

The only risk I can see is that we would be putting quite a few eggs in one
basket, however given the success of Gitlab I think that risk at this stage
should be fairly minimal (and is no higher than if we went with something
else off the shelf).

Comments?

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20220717/9fe7dedc/attachment.htm>