openSUSE:Build Service Concept User Data

Jump to: navigation, search
This text is a draft concept based on a meeting where some buildservice developers discussed this topic in december 2008. Please feel free to comment and/or change.

Storage of user related data

The openSUSE infrastructure consists of several more or less independent web applications and services. Some are huge, such as the buildservice api, others are fairly special and small, such as Hermes' starship. They use databases for data storage.

What they all have in common is that they deal with user data. In this discussion it has to be distinguished between two different types of user related information:

  1. General user information such as Name, email, openSUSE member status and such.
  2. Application specific data related to an account such as the information which packages a user maintains or which Hermes notifications somebody wants to receive in which way.

It is not applicable that every application has it's own code to check the user account, offer forms to log in, change the name or email and so on.

Currently we have a quite suboptimal situation here. Most apps still have to much own code in this area. That is in the way when it comes to single sign on experience for users for example. Furthermore we have with a subsystem which is supposed to be the user management subsystem.

We had a nice meeting with some geeks here to discuss that. This article summarizes what we came up with.


In the current openSUSE infrastructure we use iChain as the authentication system. From the application point of view, iChain proxy working mode is very smart: The application does not have to deal with passwords and login masks but can rely on a http header that contains the account name. Because of the special configuration the application can rely on that the account is existing, authenticated and valid.

That means that usually the application gets a string with a username that is logged in. This accountname is the general key, iChain garantees the uniqueness of the name.

General user data

For general user related data such as the name, emails, jabber ids and such, it was decided to maintain them in the database of users also provides interfaces to maintain these data.

Application specific data

The more specialised data that is of single interest of one subsystem is going to be stored and edited in the subsystems responsibility. For example, Hermes has to provide an edit interface for the user subscriptions to the notifications. The key for storage of the data is the iChain account name provided by iChain.

User data webservice

To provide all applications with the general user data, implements a webservice of the following form:


The return format can be specified such as text/xml or json.

This service is of course not open to the public and will for the first time secured through the iChain setup. Later it was proposed to use for cross application authentication, investigation needed.

Rails applications authentication library

Current status is that there is no common code library for the variety of openSUSE rails apps to use the iChain- or other method authentication. That is very little code and thus most apps implemented that themselves. Of course that is error prone and unflexible and needs change.

It was decided that this code should go to a commonly used code library. The library will provide the following functionality:

  • Extraction of the user token from the HTTP header
  • Test capability for the iChain authentication type for development setup (cheat the account)
  • easy plugin for other authentication types like basic auth and LDAP

Open for investigation is if the library could encapsulate getting the user info from and providing a model accordingly.