Since the rails oauth-plugin got support for oauth 1.0a I started to migrate the frontend so that it also supports 1.0a. This was a nice exercise to learn how certain things are done with rails. Additionally I did some code cleanups, bugfixing etc.

The goal for this week is more testing, bugfixing and writing a user documentation.

The task for this week was to add support to the frontend so that desktop clients like osc can add the oauth specific parameters to the http “Authorization” header. The ruby library was already able to handle this and therefore I only needed to do a very small change in our urllib2 OAuthHandler which is used by osc.

Using the Authorization header has one drawback:
– the current flow looks like the following: a client makes an unauthorized API request, the API sends back a 401 to tell the client that it needs to authenticate. Therefore the response also contains the following http header: ‘WWW-Authenticate: basic realm=”Frontend login” ‘. This indicates that the client should use basic auth to authenticate with the API. The question is how we can tell the client that it could also use oauth? Sending back something like ‘WWW-Authenticate: basic, oauth realm=”Frontend login”‘ will probably break some clients. Fortunately darix had a great idea: the client simply tells the server which auth methods it supports. This can be done by adding a new http header like ‘Accept-Authentication: OpenID; OAuth;q=0.8, digest;q=0.7, Basic;q=0.5″ ‘ to each request (q indicates which method is preferred, see other http headers like ‘Accept-Language’ for the details). If the API needs authorization it looks at this header and picks the “preferred” method from this list and sends back ‘WWW-Authenticate: <preferred_and_supported_method>, realm=”Frontend login”‘ ‘. In case the Accept-Authentication header is omitted the application’s default method is used (in our case basic auth). Another thing which needs to be discussed is how the API should behave if the client only accepts methods which aren’t supported by the API (e.g. should the API send back a 401 or 406?).

Apart from thinking about this the other task for this week(end) is to add an UI for managing oauth tokens etc. The first part of this task is to decide which tasks the UI should support (like revoking tokens, authorize tokens etc.).

The next meeting will be on monday to discuss the first results.

The goals for the last week were to implement oauth support into osc and add something like a “ttl” so that an access token expires after some time.

In order to implement it into osc I decided to write a simple OAuthHandler class which can be added as an “opener” to urllib2. So it should be possible to add custom “openers” for other protocols (but the interface might change again).

The next action item was to add a ttl for an access token. In fact this was just a “one-liner” (apart from a small migration script). I’m really impressed how easy it was to do this with rails.

One note about the osc integration:
At the moment osc sends all required authentification stuff (e.g. oauth_token etc.) via url parameters: http://0.0.0.0:3000/source/home:Admin?oauth_consumer_key=<key>&oauth_signature_method=HMAC-SHA1… because we cannot use POST requests. It might be “nicer” to add this kind of parameters to the http header – so our plan is to use the standard http authorization or www-authenticate headers (see also here).

Action item for the next week:

• add support to the frontend so that it can handle oauth via the authorization header.

In the last days I had a closer look at the oauth rails plugin which requires some methods from the restful_authentification module. As the obs frontend doesn’t use this module we need to provide our own implementations of these methods. Fortunately it only uses a handful of methods (like authorized?, login_required, logged_in?, current_user etc.) so it shouldn’t be too hard to get it working without the restful_authentication module.

Another thing on my todo list was to look for possible workarounds for the session fixation attack. According to this thread it’ll be fixed in a new revision of the oauth spec. So after the user grants access to a specific application the oauth provider redirects the user to a callback url (if it’s specified by the consumer). Additionally it adds a parameter to this url (called oauth_verifier) which has an unpredictable value – so an attacker has no chance to “take over the session” (this is just a short summary – for more details have a look at the spec).

Last but not least I finished the test application and played around with it.

TODO:

• start integrating oauth into the frontend
• play around with the python library

Btw. my mentor pointed me to an interesting railscast about authlogic – it gives a great overview about this module.

My mentor suggested to do a weekly meeting in order to discuss the current state of the project. I’m going to post a small summary after each meeting.

in progress:

• build small rails test application in order to simulate a small environment to test the ruby libraries
• used the “restful_authentication” module because it is required by the rails plugin generator

The test application is more or less working and it’s already possible to get an access token.

TODO:

• find more information and possible workarounds for the session fixation attack
• finish the test application
• find out which method’s from the “restful_authentication” module are required by the oauth rails plugin. The plan is to “fake” this methods so that the rails plugin can be used.

Additionally we talked a bit about authlogic – we decided that we won’t use authlogic for this project but it might be useful for the future.

This year I’m going to participate in the Google Summer of Code and my goal for this summer is to add support for oauth to the openSUSE BuildService. My mentor is darix. In the following I’m going to describe the project and its planned implementation a bit further.

oauth is an open protocol which describes the required steps for a client to
authorize with an API. In traditional protocols the client asks for the user’s
credentials (most-likely a pair of an username and password) and uses these
credentials to authenticate with the API. One drawback of this approach is that
the user has to trust the client that it stores the credentials in a secure way
and that it doesn’t misuse it.
oauth tries to solve these issues in a more elegant and secure way.

Small overview about oauth:
Every API (in oauth terminology “Service Provider”) has a list of known clients
which have a unique id (in oauth terminology “Consumer Key” and
“Consumer Secret”). In order to authorize the client and the API exchange so
called “tokens”.
First the client sends its unique id to the API which verifies the id to make
sure that this client is allowed to use the API. If everything is ok the API
sends back a so called Request Token (which isn’t authorized yet).
In the next step the client redirects the user to the API’s login (this request
also includes the formerly received Request Token). This is the most important
point because the user logs into the API with his/her credentials and the
client _never_ gets in touch with the username and password. After the user
logged in he/she has to approve to grant the client access. If the access is
granted the API sends back the authorized Request Token and redirects the user
back to the webclient.
In the last step the webclient exchanges the authorized Request Token for a
so called Access Token. Now the webclient will use the Access Token for all
requests it sends to the API.
The major advantage is that the webclient only knows about the Access Token
and doesn’t have to fool around with the a username and password. So in case
the webclient gets compromised the attacker can just access the API but not
the other services.

The best is to describe the oauth workflow with a small example.
Note: this example is very idealized and its sole purpose is to visualize the rough workflow of the protocol.

Let’s say the BuildService webclient and the BuildService api use the oauth protocol and the
webclient wants to fetch the projectlist:

request projectlist
webclient ——————————————————> API
API realizes that the webclient isn’t authenticated yet and it returns a 401
401
webclient <—————————————————— API
request Request Token
webclient ——————————————————> API
verify client id, send back unauthorized Request Token
webclient <—————————————————— API
redirect user to the API login
webclient ——————————————————> API
user logs in
API    <—————————————————–> API
user grant client access
API    <—————————————————–> API
send back authorized Request Token
webclient <—————————————————— API
exchange Request Token for Access Token
webclient ——————————————————> API
verify request and send back Access Token
webclient <—————————————————— API

All consecutive webclient requests contain the Access Token

request packagelist (request contains the Access Token)
webclient ——————————————————> API
verify Access Token and send back packagelist
webclient <—————————————————— API

Within the scope of this project my plan is to add basic oauth support to the following components

• frontend (API)
• osc (CLI)

To do so I might use the following libraries:

• ruby oauth library
• ruby oauth rails plugin
• python library

So the next step is to investigate how these libraries work and how they can be used for this project. I’ll blog about my investigations – stay tuned 🙂

Ps. feedback, comments etc. are welcome.