15 Authorization

15.1 OBS Authorization Methods

Each package is signed with a PGP key to allow checking its integrity on user's machines.

15.1.1 Default Mode

OBS provides its own user database which can also store a password. The authentication to the API happens via HTTP BASIC AUTH. See the API documentation to find out how to create, modify or delete user data. Also a call for changing the password exists.

15.1.2 Proxy Mode

The proxy mode can be used for esp. secured instances, where the OBS web server shall not get connected to the network directly. There are authentication proxy products out there which do the authentication and send the user name via an HTTP header to OBS. This has also the advantage that the user password never reaches OBS.

15.1.3 LDAP Mode

LDAP authentication code is still part of OBS, but due to the lack of any test cases it is currently not recommended to use it.

15.2 OBS Token Authorization

OBS provides a mechanism to create tokens for specific operations. This can be used to allow certain operations in the name of a user to others. This is esp. useful when integrating external infrastructure. The create token should be kept secret by default, but it can also be revoked at any time if it became obsolete or leaked.

15.2.1 Managing User Tokens

Tokens always belong to a user. A list of active tokens can be viewed using

osc token
osc token --delete <TOKEN>

15.2.2 Executing a Source Service

A token can be used to execute a source service. The source service has to be setup for the package first, check the source service chapter for this. A typical example is to update sources of a package from git. A source service for that can be setup with

osc add git://....

The best way to create a token is bind it to a specific package. The advantage is that the operation is limited to that package, so less bad things can happen when the token leaks.

osc token --create <PROJECT> <PACKAGE>

Also, you do not need to specify the package at execution time. But keep in mind that such form only works when you run it on an as checkout of a package. Both commands below do the same thing in a different way:

osc token --trigger <TOKEN>
osc api -X POST /trigger/runservice?token=<TOKEN>

A token can be registered as generic token, means allowing to execute all source services in OBS if the user has permissions. You can create such a token by skipping project/package on creation command:

osc token --create

In this case you forced to specify project/package when using such a token. On other hand you not limited from where two execute it. Again two examples doing same thing:

osc token --trigger <TOKEN> <PROJECT> <PACKAGE>
curl -H "Authorization: Token <TOKEN>" -X POST /trigger/runservice?project=<PROJECT>&package=<PACKAGE>

You can also limit the token to a specific package. The advantage is that the operation is limited to that package, so less bad things can happen when the token leaks. Also you do not need to specify the package on execution time. Create and execute it with

osc token --create <PROJECT> <PACKAGE>
osc token --trigger <TOKEN>
curl -H "Authorization: Token <TOKEN>" -X POST /trigger/runservice
Print this page