36 Authorization #
36.1 OBS Authorization Methods #
Each package is signed with a PGP key to allow checking its integrity on user's machines.
36.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.
36.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 also has the advantage that the user password never reaches OBS.
36.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.
36.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.
36.2.1 Managing User Tokens #
Tokens always belong to a user. A list of active tokens can be viewed using
osc tokenosc token --delete <TOKEN>36.2.2 Executing an Action #
A token can be used to execute specific operations. This can be a source service trigger, a rebuild call, or release action. The setup needs to be prepared for the action. For example 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 but 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 --createIn this case, you are forced to specify project/package along with the token. On the other hand, you are not limited from where you execute it. Again, two examples doing same thing:
osc token --trigger <TOKEN> <PROJECT> <PACKAGE>curl -H "Authorization: Token <TOKEN>" -X POST https://$obs_instance/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/runserviceA token to rebuild a package can be created and trigger by
osc token --opertion rebuild --create <PROJECT> <PACKAGE>osc token --operation rebuild --trigger <TOKEN>curl -H "Authorization: Token <TOKEN>" -X POST https://$obs_instance/trigger/rebuildA token to release a package can be created and trigger by
osc token --opertion release --create <PROJECT> <PACKAGE>osc token --operation release --trigger <TOKEN>curl -H "Authorization: Token <TOKEN>" -X POST https://$obs_instance/trigger/release