#4840 accepted infra

Single Sign On using GitLab instance

Reported by: Christian Mauderer Owned by: Amar Takhar
Priority: normal Milestone: Indefinite
Component: admin Version:
Severity: minor Keywords: need-funding project-2
Cc: Blocked By: #4790
Blocking:

Description

If we migrate to a new system, it should support authentication with well-known services to reduce the hurdle for new users.

The GitLab that is suggested in #4790 supports for example

Change History (5)

comment:1 Changed on 02/07/23 at 15:18:17 by Amar Takhar

Owner: set to Amar Takhar
Status: newassigned

We've had this discussion in the past and the consensus was to keep everything related to RTEMS on RTEMS infrastructure. Dealing with OAUTH is not fun we'll have our own GitLab? instance to carry users as an SSO.

From an infrastructure and maintenance point of view it's far easier to keep everything one spot versus "everything but one thing".

There are also plenty of users who absolutely refuse to use 3rd party services for this and if we want to support them then we end up with a hybrid system where we have local users and remote users any time we want to interact with them we'll have to deal with full or partial data as different services limit user data in different ways. It becomes a mess of data requests and interstitial pages from different services -- that becomes a moving target as OATH changes and services update. Plenty of old systems are just broken now due to changes in OATH and how services handle the signon itself.

It's just an absolute mess to deal with I would like to avoid this for a currently unfunded project such as ours.

comment:2 Changed on 02/07/23 at 15:18:35 by Amar Takhar

I'll leave this ticket open for a bit in case anyone else would like to chime in.

comment:3 Changed on 02/07/23 at 15:40:59 by Christian Mauderer

I agree that local authentication has to be always possible as a primary option. Missed to mention that because I thought it is obvious. Other services should always only be an additional option.

I would expect that GitLab more or less has every user as a local one in it's database and only allows to authenticate using another account. For example on the GitLab.com instance, I can add multiple authentication methods to my account. I then can login into the same account either by using user and password or by using (for example) GitHub? or Google.

Advantage for a user is that he can just use an existing accounts without registering to another service. Some might prefer this lazy method.

Of course that will be a feature that will be only there if someone pays for it - like a lot of other features in other tickets.

comment:4 Changed on 02/07/23 at 15:49:53 by Amar Takhar

Even if someone does fund this work they won't be funding the amount of work it takes to keep it running. The transition from OATH 1 to 2 was brutal and still is and now there is OATH 2.1 which probably should have been OATH 3 as it does involve breaking changes.

It's just not something we can keep up with. It's different if we're hosting it ourselves as we can then call it a one-time funded issue if we update GitLab? and OATH changes that becomes part of that funded work.

Without anyone paying for ongoing maintenance it's not something we could even consider taking on and with the project having decided to self-host it's a non issue regardless it's better to keep all our data locally so we can guarantee the safety of that data to our users.

comment:5 Changed on 02/07/23 at 20:30:17 by Amar Takhar

Keywords: project-2 added
Milestone: Indefinite
Status: assignedaccepted
Summary: Authentication with well known services for RTEMS infrastructureSingle Sign On using GitLab instance

I'm changing the title to Single Sign On and keep this around to ensure it's done as part of project-2.

We'll be using our GitLab? instance to handle all SSO for the Wiki as well as Buildbot or any services going forward. This means:

  • No duplicate accounts for any service that requires user signup
  • In rare cases developers of RTEMS may have a secondary account if the service is deemed as a must.
Note: See TracTickets for help on using tickets.