Reference Guide
- About this Guide
- 1 OBS Architecture
- 2 OBS Concepts
- 3 Build Process
- 4 Source Management
- 5 Request And Review System
- 6 Image Templates
- 7 Multiple Build Description File Handling
- 8 Maintenance Support
- 9 Binary Package Tracking
- 10 Administration
- 11 Scheduling and Dispatching
- 12 Build Job Constraints
- 13 Building Preinstall Images
- 14 Authorization
- 15 Quality Assurance(QA) Hooks
- 16 openSUSE Factory
- Glossary
- A GNU Licenses
14 Authorization
14.1 OBS Authorization Methods #
Each package is signed with a PGP key to allow checking its integrity on user's machines.
14.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.
14.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.
14.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.
14.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.
14.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>14.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 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 /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