openSUSE admin

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.

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.

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.