Project

General

Profile

Actions

tickets #122254

open

Migrate away from login proxies to SSO

Added by hellcp almost 2 years ago. Updated 7 months ago.

Status:
New
Priority:
Normal
Category:
Core services and virtual infrastructure
Target version:
-
Start date:
2022-12-20
Due date:
% Done:

0%

Estimated time:

Description

It would be nice to slowly migrate over to using SSO instead of login proxies for logging into our infrastructure. The list below covers all of the services that still use login proxies. Some of them aren't under our jurisdiction, some may not even have login capabilities, but they still are behind login proxies, because why not (they shouldn't be, get them out of there).


Checklist

  • progress/tickets(+test)
  • tsp(+test)
  • amqp/rabbit
  • api/obs-*/registry/build(+test)
  • wikis,files
  • connect
  • elections(+test)
  • errbit
  • events(+test)
  • gs-stats(+stage)
  • hackweek
  • id
Actions #1

Updated by hellcp almost 2 years ago

  • Private changed from Yes to No
Actions #2

Updated by adamm almost 2 years ago

Keep in mind that for OBS, the API does not really have a notion of login. Authentication is currently done only via a cookie/http authentication. To solve this, we should add a service that allows for all API to be of the form

api_call(token, ....)

where the token is a login token in-lieu of the cookie or the HTTP Authentication header. To generate this token, this will need additional login() and logout(token) handling.

TL;DR: We'll need (to develop) an intermediate service to replace the proxy. This will make authentication more secure while at same allow for data driven front end applications.

Actions #3

Updated by hellcp almost 2 years ago

adamm wrote:

Keep in mind that for OBS, the API does not really have a notion of login. Authentication is currently done only via a cookie/http authentication. To solve this, we should add a service that allows for all API to be of the form

api_call(token, ....)

where the token is a login token in-lieu of the cookie or the HTTP Authentication header. To generate this token, this will need additional login() and logout(token) handling.

I don't really see much of a reason to have login and logout handling from the outside of the application, having a token means that that token is already registered with the application, so just providing it with the request you are making to the server is enough to authenticate. I am also not a big fan of handling "logout" or token invalidation and other token methods outside of application, since that may lead to abuse.

OBS also does already have tokens, they are a bit limited in scope right now, but could be a base for such a system in the future.

In any case, that is in the back of my mind at all times, I have just developed paste-o-o which does implement an auth system which allows you to create and use keys for authenticating into api, while also authenticating you with openid connect in the web ui (from which you can manage your auth keys), so I may end up trying my luck in OBS, so that we can do auth with oidc there too.

Actions #4

Updated by adamm almost 2 years ago

rhellcp wrote:

adamm wrote:

where the token is a login token in-lieu of the cookie or the HTTP Authentication header. To generate this token, this will need additional login() and logout(token) handling.

I don't really see much of a reason to have login and logout handling from the outside of the application, having a token means that that token is already registered with the application, so just providing it with the request you are making to the server is enough to authenticate. I am also not a big fan of handling "logout" or token invalidation and other token methods outside of application, since that may lead to abuse.

logout() allows for invalidating a login outside of timeout. It can be useful.

OBS also does already have tokens, they are a bit limited in scope right now, but could be a base for such a system in the future.

Maybe unfortunate wording by me, I meant just a token like the openSUSE cookie used for authentication. Web applications (like the ones in a browser) have no access to cookies and barely to HTTP Authenticate headers -- it's awkward and outside of normal API.

In any case, that is in the back of my mind at all times, I have just developed paste-o-o which does implement an auth system which allows you to create and use keys for authenticating into api, while also authenticating you with openid connect in the web ui (from which you can manage your auth keys), so I may end up trying my luck in OBS, so that we can do auth with oidc there too.

:+1:

The use of login proxy for OBS API has bothered me for some time now too but I''ve not had time to do anything about it yet. It makes OBS security a little less than ideal as any application in the opensuse.org domain could basically "borrow" the credentials to issue OBS requests.

Actions #5

Updated by crameleon over 1 year ago

  • Checklist item progress/tickets(+test) set to Done

progress.o.o will move to OIDC as part of the Redmine upgrade in #133532 - progress-test.o.o already uses it.

Actions #6

Updated by crameleon 12 months ago

  • Checklist item deleted (jitsi)
Actions #7

Updated by crameleon 7 months ago

  • Checklist item deleted (software(+stage))
  • Checklist item connect set to Done
  • Checklist item gs-stats(+stage) set to Done
  • Checklist item id set to Done
Actions

Also available in: Atom PDF