Openid Proposal
 

 

Title: OpenID Support for openSUSE Build Service
Student: udit sajjanhar
Abstract: The goal is to have a instance of the Build Service where users can log in with an OpenID.

The specific requirements are:

* Enabling users to login and register with OpenID
* OpenID UI for the Web front end
* Associating an API key with user
* Extending the Authentication mechanism of API to support login via API key
* Evaluating/Implementing OAuth to provide access to API

Login through OpenID will provide a better user experience to the Web Front end users.
Content:

Proposal by Udit Sajjanhar

1. Using OpenID for login and registration

1.1 Work Flows

For this project OpenID based Authentication can be integrated in three work flows

Registration

  1. User comes to the registration page and sees the option of registering by using OpenID
  2. On choosing the OpenID option, user is asked to enter his OpenID Url
  3. The system redirects to the provider asking for information about user
  4. On successful response by the Provider, the user is asked to fill in the remaining details.

Login

  1. If User chooses to login via OpenID, he is asked to provide the open id url.
  2. The system redirects to the Provider.
  3. On successful response by the Provider, the user is logged in.

Adding More OpenID Urls

  1. User goes to the setting area and inputs an OpenID.
  2. The system redirects to the Provider.
  3. On successful response by the Provider, the new OpenID for the user is stored.

This work flow can be used by the users to add more than one OpenID or by existing users who don't have an OpenID registered.

1.2 Implementation

To implement the above work flows, the following things need to be implemented:

  1. A one to many mapping from users to open ids would have to stored in database
  2. UI for Registration and login with OpenID would have to be created
  3. UI for adding more than one OpenID
  4. Infrastructure for OpenID communication with the Provider
  5. Appending the Login Infrastructure to support OpenID based login

For communicating with the Provider, a ruby-openid gem is available. Installing this gem to the Rails environment would suffice for point 4 above.

2. Associating API Key with user

2.1 Generation of API key

If we have too choose between generation of key on request or automatically, the on request would be a better option. On request option will allow us to track the number of users who are actually using the API through Key.

API key can generated by calculating an MD5 Hash of user_id, current_time and and special secret string.

User will required to submit a request for the API key from the web interface.

2.2 Key Association

Since each user will have a unique key, the key can be stored in users table, in database.

2.3 Changing the API Key

User will be given an interface to request the change of API key. On submission of request, user will be sent the details of the new API key by email.

3. Extending Authentication mechanism of API

3.1 Need

If the user has registered with OpenID then he doesn't have a username or password. For this user the API would become useless, since it requires the user to login first. To solve this problem we can use the following approach:

3.2 Proposed Approach

When the user requests for an API key, then along with the API key, user is sent a secret pass too. To authenticate the API key the user will submit the following three things

  1. API key
  2. timestamp (UNIX timestamp)
  3. MD5 hash of concatenated string made out of secret and timestamp

The server will not accept timestamps older a pre-defined period of time. Hash of the timestamp and secret enforces more security. Even if someone evedrops on the submitted parameters they will have the access for only the pre defined amount of time.

4. OpenID support for Web Interface of API

The API also has a web interface which will be required to support OpenID. As mentioned in the Wiki, the authentication will take place on the main website's OpenID page. However after a successful authentication the user will be redirected to the web interface and the API key will be present in the parameters. This API key will stored in the session and can be used further.

To do this, it will be required that when the user is redirected to the main website's OpenID login page, then a parameter is passed indicating that the user has to be redirected back to the web interface of the API

5. OAuth to provide access to API

The use of OAuth to provide access to API seems unclear. OAuth is a Framework to provide sensitive/personal data to a consumer website through a provider's website. A more elaborate use case is explained here. However this use case doesn't fit into the paradigm of providing the access to API. If anyone from the OpenSuse community has a understanding of this, it can be pointed out in the comments and can be incorporated in the proposal.

Development Steps

Step 1: fixing of requirements and finalizing project timeline
Step 2: adding OpenID support to login and registration
Step 3: Refactoring the existing code to support OpenID login
Step 4: Testing OpenID support
Step 5: Association of API key with user. Development of UI support for the same
Step 6: Testing of API key Association
Step 7: Implementation of API Authentication via key
Step 8: Testing the new API Authentication
Step 9: Adding OpenID support to Web Interface of API

Timeline

Bonding Period + Week 1: Step 1
Week 2 + Week 3:Step 2
Week 3 + Week 4: Step 3
Week 5: Step 4
Week 6 & Week 7: Step 5
Mid Term Evaluation
Week 8: Step 6 and Incorporating Mentor's feedback
Week 9 & Week 10: Step 7 & Step 8
Week 11 & Week 12: Step 9
Last two days:Documentation :)





On 31st March 2009 10:08 Cornelius Schumacher wrote:

Some additional questions: What's your experience with openSUSE, packaging, and the Build Service? Have you looked at the Build Service code? Have you tried to get an instance of the Build Service running on your own system?

On 1st April 2009 11:14 udit sajjanhar wrote:

Hi Cornelius,

What's your experience with openSUSE, packaging, and the Build Service?

I have used OpenSuse Build service for searching and downloading packages. I have never built my own package.

Have you looked at the Build Service code? Have you tried to get an instance of the Build Service running on your own system?

Yes, I had checked out Build Service code and ran the web front end. I was able to figure out that the code used API Resource via REST instead of using the local database. I was able to login with the same same login as build.opensuse.com.

 

It would be great if I could get feedback on my poposed approaches:

  1. to extend the authentication mechanism of API
  2. to associate API Key with User
  3. OpenID support for web end

 

 

On 2nd April 2009 17:53 udit sajjanhar wrote:

A couple of questions:
- Where would you implement the to register, login, and add multiple OpenIDs on the frontend or the web client?

Implementation of register, login and add multiple OpenIDs would take place on the web client. More specifically in the Rails code that runs on build.opensuse.com.


- The implementation proposal for OpenID sounds fine.

Thanks. :)


- I agree on generating the API key on request. What would be the advantage of the method you described over just generating a random string?

Generating the API key via MD5 hash would be more secure and has a better chance of being unique.

The irreversibility of MD5 makes it difficult to guess the input parameters or the algorithm used to generate it. On the other hand if we start with the same seed value, same sequence of random strings will be generated.


- Why would you send the API key by email and not just show it in the UI?

Theres no harm in not sending the API key on email and just showing it in the UI.


- I don't think evedropping the API traffic is a problem. Would you still think we would need the security measures you describe in section 3.2 of your proposal?

Even if evedropping is not the problem, taking extra security measures would prevent misuse. This would make it hard for anyone to guess an API key and start misusing. API should be authenticated/verified.

On 2nd April 2009 23:47 Cornelius Schumacher wrote:

Just for clarification: If the UI code for login and OpenID handling is on the web client, how would the API get the API key which is needed to access it? Remember that the web client is just using the API as a backend.

On 2nd April 2009 23:50 Cornelius Schumacher wrote:

Your development steps and timeline don't show time for refactoring the current code to make it possible to implement OpenID as an alternative login system instead of the currently used. This probably is a significant part of your work. Could you put that in?

On 2nd April 2009 23:52 Cornelius Schumacher wrote:

Final question for now: How do you feel about discussing your work on public mailing lists and IRC? What's the role of the community for you?

On 3rd April 2009 07:31 udit sajjanhar wrote:

Just for clarification: If the UI code for login and OpenID handling is on the web client, how would the API get the API key which is needed to access it? Remember that the web client is just using the API as a backend.

Currently the API authenticates the user by login and password. With the new approach:

If user is using the command line tool, the API authenticates the user as described in section 3.2, and stores the information in session.

When using the web client and logging in by OpenID, we can follow the following procedure:

1. Before sending the request to the OpenID provider the web client sends the openid url to the API and gets back a token.

2. The Return url prvoided to the provider is something of the type api.opensuse.com/:open_id_url/:token

3. On receiving the confirmation from the provider, the API will autheticate the user through the web client.

4. The webclient can then make requests to the API in the usual manner.

This is the best approach that I could think of. Any suggestions here would be welcome. :)

Your development steps and timeline don't show time for refactoring the current code to make it possible to implement OpenID as an alternative login system instead of the currently used. This probably is a significant part of your work. Could you put that in?

Done.

Final question for now: How do you feel about discussing your work on public mailing lists and IRC? What's the role of the community for you?

As matter of fact I had been lurking on the opensuse channel from the last two days. I will surely discuss this idea with the opensuse community. The role of community is really core to the development of opensouce software.

On 3rd April 2009 08:03 Cornelius Schumacher wrote:

Do you have experience with test-driven development?

On 3rd April 2009 08:48 udit sajjanhar wrote:

Do you have experience with test-driven development?

I am one of the lead developer of Intinno(http://www.intinno.com) a Course Management System, written fully in RoR.  We have followed the Behavior Driven Development(BDD) in our project. We have used Rspec Plugin for this purpose and wrote specifications for all the models in our system.

On 9th April 2009 17:59 brandon philips wrote:

Why are you thinking about implementing an API key AND OAuth. The simplest solution would be to implement the one growing standard: OAuth.

On 12th April 2009 06:00 udit sajjanhar wrote: