[super] Authorization

[teleyinex]

It is important to discuss the minimum requirements that PyBossa will have according to authentication and authorization.

NB: Authentication in WUI already works and API key autentication is #20.

Authentication: for the moment there is a basic authentication method, that allows users to create an account, sign in and sign out.

Authorization: it is mandatory to identify which actions will be valid for different types of users. For the moment I think that the following roles will be possible:

• Project managers: these users will be able to administer all the registered applications within the service. Thus, they will be able to create, update and delete applications, as well as all their associated data.
• Users: these type will be allowed to participate in different applications registered in the system, as well as creating their own applications thanks to the UUID API key which is generated when you register an account. For these reasons, these users will be able to: create, update and delete their own applications as well as the associated data (tasks of the applications created by the user).
• Visitors: it could be interesting to allow visitors contributions to different applications. Thus, there should be an option within the creation of the applications to allow visitors contributions. Visitors contributions could be very valuable as it will help new users to try the system and get involved without all the problems of registering, at first, a new account. These type of accounts will allow to play directly and contribute as in Wikipedia or GalaxyZoo.

@nigini, @rgrp it will be interesting to have your comments and feedback about these items.

Additional proposal (from RP -- but please mod)

NB: I think it would also be useful to have listed relevant user stories (or, at least, situations). That would help us check we have covered edge cases.

Situations - CRUD on core domain objects

App

• Create: User creates an App (Visitor cannot create app). User becomes owner of app
• User updates an App (user must be owner of App)
• User deletes an App (ditto)
• Anyone can view an App unless it is hidden (in which case only owner can view)
  • Listing is same as viewing except we hide hidden from everyone including owner (to avoid special-casing)

    Task

Tasks are always related to an App.

• Create: Only App owner can create Tasks for their app
  • TBD: could an application have collaborators to submit tasks?
• Read: anyone can access
• Update: only app owner
  • TBD: collaborators?
• Delete: only app owner
  • TBD: collaborators?

    TaskRun

• Create: Only logged-in users can create TaskRuns
  • RP: Should we have a special flag on tasks that indicates it can be run by anyone including non-logged in? Seems useful to allow some visitors contribution.
  • DLG: Yes, I think that a flag will be enough, so app owners can see which tasks have been submitted by visitors or registered users. +1 to this!
• Read:
  • The owner can read all the TaskRuns from his application.
  • The User can read all his created TaskRuns.
  • RP: why not allow everyone to read task runs - it allows them to build stats apps of their own
  • DLG: apparently it could influence other people answers, but we can discuss this at a later stage. Thus, I agree with you for this point. +1 to this.
• Update: all registered Users can update their TaskRuns (i.e. fixing errors)
  • Visitors task runs cannot be updated.
• Delete: all registered Users can delete their TaskRuns

  Implementation

See these two (almost identical implementations):

• https://github.com/okfn/openspending/tree/master/openspending/auth
• https://github.com/pudo/datahub/tree/master/datahub/auth

Even simpler option:

• https://github.com/okfn/webstore/blob/master/webstore/security.py

[nigini]

1- I think the API ID should not be related to the User, but to the Applications. It will be important to know statistics about API calls by App, and not by users. (at least it is like this at Twitter, Facebook, and others)

2- Inside an Application it will probably be needed the "App Admin" role, where its creator will be the first one and will invite other users to join this.

[teleyinex]

@nigini I think that your two points are really valuable! Unless, @rgrp thinks different, we should proceed with your idea.

[rufuspollock]

To clarify: I've added to main overview a general approach from elsewhere that I've found useful. Specific comments:

@teleyinex

• Flask-Login handles cookie based remembering of your identity and a standard way to share it with templates. Actual identification is done by sign-in code in account/view.py

@nigini:

• not sure about the API ID being related to App. Think this would need to be explained a bit more to me :-)

[teleyinex]

@rgrp I just removed the Flask-Login sentence from the first comment.

[teleyinex]

@rgrp I have added some comments to your proposal, and I have fulfilled the TaskRun object.

[teleyinex]

I have updated also the user stories, so we can include them here.

[nigini]

@rgrp! About the API KEY, a user may have many applications, and can share app's administration with other users. If you have an API KEY per user, you will easy expose data from all your application once other developer is invited to help you at one of them. Other important thing is to have API call statics per application, what can be easily done using an APP-KEY.

I imagine that the community have other explanations to do it like this (and I will start studing more about API to help here), but a good plus to this idea is that Google, Twitter and Facebook all implements its services like this.

[teleyinex]

I support @nigini idea, as I see that it could be a problem to have only one owner per application. Thus, a user story for this case would be the following (obviously from my point of view):

As a project organizer I would like to create, update and delete applications becoming the owner of the application. As a project organizer I would like to invite other colleagues to help me to administer my applications, giving them the following permissions:

• To Create, Update and Delete Tasks for a given application that I own.
• To make one of the colleagues the owner of the application, as I cannot work on it anymore (this action will give all the admin rights to the colleague, demoting me?).

[rufuspollock]

I've made some minor tweaks to proposal around allowing anonymous visitors to still do task runs.

@teleyinex agreed that definitely nice to have co-administrators but wonder if this is something to leave for the future when the need has clearly arisen. We can probably get by in a first version without this and we should focus on "minimum viable product" (aka You ain't gonna (or may not) need it).

@nigini still not sure i get need for per-task API keys. If you want other collaborators to have access to your app I'd suggest we do this via an explicit collaborator system rather than sharing around a common API key.

[nigini]

@rgrp I agree that are other ways to do it, but I still will search for why the big ones adopts this APP-KEY solution.

[teleyinex]

I have updated the issue: I have unified the term anonymous to visitor to have the same terminology for the issue.

@rgrp fine! Let's move to the next stage, so we can start coding asap.

@nigini and @rgrp which approach do you want to use for this v0.1 (API key)?

[rufuspollock]

I've clearly suggested that we leave API key as is: i.e. on per user (let's keep it ultra-simple!).

In terms of implementation I've added some comments to the main ticket.

[nigini]

OK @rgrp and @teleyinex!

I've readed the code that was pointed at the ticket, but if I'm not wrong, they are focused at authorization. As I'm interested in learning about these king of web development patterns, I was reading about OAuth. I've found this great tutorial about authentication with this pattern.

May I use these coding examples to draft something?

[teleyinex]

Hi,

I think that we have finally something :) Thus, the authentication will be kept: Flask-Login + API key per user. This solution enables two types of users:

• Authenticated users: two types: PyBossa admins and authenticated users.
  • CRUD actions:
  • admins: All CRUD actions: they manage the whole site.
  • users:
    • CRUD applications (their own applications).
    • CRUD tasks for their applications
    • CRUD taskRuns owned by them
• Non-Authenticated users: aka visitors
  • CRUD actions:
  • R applications (not hidden ones)
  • R tasks from apps
  • CR taskRuns

Everyone agrees to proceed?

[rufuspollock]

@nigini this ticket is in fact primarily about authorization (authentication could be dropped). If you want to code stuff re oauth outside of PyBossa please go ahead though I note that there is straightforward support for oauth in Flask via the Flask OAuth extension http://packages.python.org/Flask-OAuth/

@teleyinex we're good to go (and i'd suggest that we keep overall summary of what we are doing in the main description of the ticket so we can refer to it later (i've updated yesterday and I think is same as yours)

[nigini]

Sorry guys. I've mixed this issue with the #20 one. Everything I've posted here was related to the API security. Should I rewrite that issue with these observations I've posted here?

[nigini]

@rgrp @teleyinex I've read the suggested code at this issue description and vote for the second one (datahub). I've talked to @pudo (code author) about the solution and he still uses it.

But before I start, I would like to know if you know this library: http://pypi.python.org/pypi/Flask-Principal It probably does something really similar with pudo's solution but it's a Flask extension. The problem is that it's a beta version since 2010!

Do you think it's a good moment to analyse this option? Or should we go with something that's already known?

[teleyinex]

@nigini I have check the web about Flask-Principal and in general no one is using it :) It seems like the popular solution is to create a tailored solution for the project. Thus, let's go for @rgrp solutions!

[nigini]

OK! I'll start today!

[teleyinex]

@nigini can you wait a bit? I'm already assigned the task to me today, and I'm finishing right now the authentication + authorization just for applications. Then, when I submit the code, you can follow the same style.

[rufuspollock]

API pretty much done (though not completely tested). Application create also done in WUI and at the moment nothing else.