22 Authorization

22.1 OBS Authorization Methods

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

22.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. Please see the api documentation to find out how to create, modify or delete user data. Also a call for changing the password exists.

22.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.

22.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.

22.2 OBS Token Authorization

OBS 2.5 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.

22.2.1 Manage tokens of a user

Tokens belong always to a user. A list of active tokens can received via

osc token
osc token --delete <TOKEN>

22.2.2 Execute 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://....

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 and execute operation with

osc token --create
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

22.2.3 Change Request Review Status

NOT YET IMPLEMENTED

Print this page