== Authentication and Authorization module ==
== Requirements list ==
=== Authentication ===
 * Forms of Authentication:
  * Database (user-pass) (must)
  * OpenID (could)
  * IP-based (could)
  * LDAP-based + specific flavors like RUG and UMCG login (should)
 * Registration of users includes email verification (must)
 * Users should be able to login and logout (must)
 * Users should be able to change their passwords (must)
 * Make implementations of Login singletons so that they can be accessed everywhere (must)
=== Authorization ===
 * Resources are tables, rows, columns, query-sets (e.g. only the Lengths in rows where Length > 1.80m), files (for pipelines)
 * Subjects are users, groups, public users (unauthenticated) and exactly one administrator
 * Permissions include read, write (also implies delete), execute (for pipelines) and ownership
 * Modifying (insert, delete, alter) a column is not supported.
 * Modifying a row needs write rights on the row.
 * Resources must have exactly one owner; this can either be a user (must) or a group (should). The latter option is not preferable for us and needs to be set explicitly by the administrator.
 * Permissions are provided for resources x subjects. (must)
 * The administrator has all permissions excluding ownership on all resources. (must)
 * Authenticated users can request permissions for resources. Requests are sent to the user or group with ownership rights of the resource. (must)
 * Groups can be created by users who have write rights on the MolgenisGroup table. The administrator is the owner of the MolgenisGroup table and can delegate rights to other users. (must)
 * In case of an UpdateDatabase all permissions are reset (except for administrator).
 * The public user has by default no reading permissions on any resource, unless explicitly set by the administrator. (should)
 * Administrator can pass on permissions from parent tables to child tables and between xref-linked tables with a toggle button. (should)

=== Example ===

''Table: !ObservedValue''

|| || read || write || execute || ownership ||
|| User1 || x || x || x || x ||
|| User2 || x || || x || -(?) ||
|| Group1 || || x || || -(?) ||
|| Group2 || x || x || x || -(?) ||
|| ... || || || || ||
|| Admin || x || x || x || - ||

== Low-level specifications for the Authorization module ==
Goal: to have a first version of the Authorization module that fulfills at least the 'must' requirements.

 * Users will be stored in the !MolgenisUser table. Furthermore, there will be one Administrator and one Public User.
 * Table rights: these will be managed through a new bridge table in which each row links to a !MolgenisEntity (through its name) and a !MolgenisUser. There will also be a field 'rights' that details the kind of authorization (an enum consisting of read, write, execute and owner). This way we can achieve many-to-many relationships.
 * Column rights: these we can achieve through an extra, optional field in the Table rights table. This field can contain zero or more names of fields (columns) in the table in question. If none are supplied, the entry is supposed to hold for all fields in the table. If one or more are supplied, the entry is supposed to hold only for the specified fields. There can be multiple entries in the bridge table for a certain table. In that case, the more detailed entries take precedence over the more general ones.
 * Row rights: for this we introduce another optional field in the Table rights table, namely an xref to a row in the table in question. Every row already has an (autogenerated) id field so this is easily done. With this extra field in place we can have very specific entries detailing what rights a certain user has on a combination of a column and a row in a certain table (so we can in fact have "cell rights"). The remark about precedence for the column rights also holds for this.
 * So we end up with one extra bridge table having entries for combinations of tables, columns, rows, users and kinds of rights. All queries should involve joins with this table to restrict the result set based on what the current user is allowed to see/edit/execute. We have to find out what this will do with the performance of our applications!

[[BR]]
[[BR]]

----

[[BR]]
[[BR]]

== Needs of the PhenoFlow module (lifelines, bbmri, gids2.0, col7a1, xgap) ==
PhenoFlow is the user interface for searching, browsing and extracting phenotype data from the Pheno model. This browsing module will be central in most of our applications.

The systems (that will be) using this module are

 * LifeLines (datawarehouse)
 * BBMRI-NL (biobank catalog) and
 * gids (2.0).
 * COL7A1 Phenotype/Patient browser (here one gene == one investigation)
 * XGAP data browser

Requirements:

 * Users need to be able to login
 * All registered users have edit permissions to create new investigations
 * All existing investigations can only be listed (names) but no other values
 * All investigations are owned by one or more persons
 * If not yet owned, users can request to become manager of an investigation.
 * Otherwise users can request read access to the investigation
 * Users can create groups of themselves (except for lifelines)
 * Users can share an investigation and all its components to [public, groups, whitelists of users) for viewing
 * The sharing rules can be read or write (so that means they can transfer management of an investigation)
 * All InvestigationElement inherit the sharing rules set on an investigation (hence, if the investigation is public so are all its elements)
 * Individual investigation elements, and the dataelements that refer to them can have different permissions (lifelines)

Issues:

 * What about data that is not an Investigation/InvestigationElement?

See www.myexperiment.org for some inspiration on how this 'sharing' model can work. See www.myexperiment.org for some inspiration on how this 'sharing' model can work.

== Needs of the xQTL Workbench ==
Requirements:

General:

 * All data input/output needs to be closed / secured
 * Unregistered users can still view public datasets

User:

 * Users need to be able to register (as users)
 * Confirmation email to the registrar
 * Users need to be able to register/confirm their email
 * Users need to be able to login
 * When loged in users are able to view public datasets and their own datasets

Admin:

 * Administrators need to be able to: Authenticate users, Ban users, Delete unused accounts
 * Administrators are not able to register, view all,execute all
 * Users cannot be promoted to admin, admins cannot be demoted to users
 * Admins donnot register, but are 'hardcoded' into the application