openSUSE:Build Service Concept User 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:
- General user information such as Name, email, openSUSE member status and such.
- 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 http://users.opensuse.org 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.
iChain
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 http://user.opensuse.org. 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, users.opensuse.org implements a webservice of the following form:
GET http://users.opensuse.org/user/<username>
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 http://oauth.net 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 users.opensuse.org and providing a model accordingly.