| 3 |  | * Authentication | 
                        | 4 |  | * (local) database | 
                        | 5 |  | * OpenId | 
                        | 6 |  | * LDAP | 
                        | 7 |  | * IP based | 
                        | 8 |  | * ... | 
                        | 9 |  | * Authorization | 
                        | 10 |  | * Permissions | 
                        | 11 |  | * read | 
                        | 12 |  | * write (create, update, delete) | 
                        | 13 |  | * execute | 
                        | 14 |  | * Resources | 
                        | 15 |  | * tables | 
                        | 16 |  | * rows | 
                        | 17 |  | * columns | 
                        | 18 |  | * files | 
                        | 19 |  | * ... | 
                      
                        |  | 7 | === Authorization === | 
                        |  | 8 | * Resources are tables, rows, columns, files (for pipelines?) | 
                        |  | 9 | * Subjects are users, groups, public users (unauthenticated) and exactly one administrator | 
                        |  | 10 | * Permissions include read, write, execute (for pipelines?) and ownership | 
                        |  | 11 | * Resources must have exactly one user with ownership rights | 
                        |  | 12 | * Permissions are provided for resources x subjects | 
                        |  | 13 | * The administrator has all permissions excluding ownership on all resources | 
                        |  | 14 | * Authenticated users can request permissions for resources. Requests are sent to the user with ownership rights of the resource. | 
                        |  | 15 | * 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. | 
                        |  | 16 | * In case of an UpdateDatabase all permissions are reset (except for administrator) | 
                        |  | 17 | * The public user has reading permissions on all resources | 
                        |  | 18 | * Administrator can pass on permissions from parent tables to child tables with a toggle button | 
            
                      
                        | 36 |  | * Users need to be able to login | 
                        | 37 |  | * All registered users have edit permissions to create new investigations | 
                        | 38 |  | * All existing investigations can only be listed (names) but no other values | 
                        | 39 |  | * All investigations are owned by one or more persons | 
                        | 40 |  | * If not yet owned, users can request to become manager of an investigation. | 
                        | 41 |  | * Otherwise users can request read access to the investigation | 
                        | 42 |  | * Users can create groups of themselves (except for lifelines) | 
                        | 43 |  | * Users can share an investigation and all its components to [public, groups, whitelists of users) for viewing | 
                        | 44 |  | * The sharing rules can be read or write (so that means they can transfer management of an investigation) | 
                        | 45 |  | * All InvestigationElement inherit the sharing rules set on an investigation (hence, if the investigation is public so are all its elements) | 
                        | 46 |  | * Individual investigation elements, and the dataelements that refer to them can have different permissions (lifelines) | 
                      
                        |  | 41 |  | 
                        |  | 42 | * Users need to be able to login | 
                        |  | 43 | * All registered users have edit permissions to create new investigations | 
                        |  | 44 | * All existing investigations can only be listed (names) but no other values | 
                        |  | 45 | * All investigations are owned by one or more persons | 
                        |  | 46 | * If not yet owned, users can request to become manager of an investigation. | 
                        |  | 47 | * Otherwise users can request read access to the investigation | 
                        |  | 48 | * Users can create groups of themselves (except for lifelines) | 
                        |  | 49 | * Users can share an investigation and all its components to [public, groups, whitelists of users) for viewing | 
                        |  | 50 | * The sharing rules can be read or write (so that means they can transfer management of an investigation) | 
                        |  | 51 | * All InvestigationElement inherit the sharing rules set on an investigation (hence, if the investigation is public so are all its elements) | 
                        |  | 52 | * Individual investigation elements, and the dataelements that refer to them can have different permissions (lifelines) | 
            
                      
                        | 66 |  | * Users need to be able to register (as users) | 
                        | 67 |  | * Confirmation email to the registrar | 
                        | 68 |  | * Users need to be able to register/confirm their email | 
                        | 69 |  | * Users need to be able to login | 
                        | 70 |  | * When loged in users are able to view public datasets and their own datasets | 
                      
                        |  | 70 | * Users need to be able to register (as users) | 
                        |  | 71 | * Confirmation email to the registrar | 
                        |  | 72 | * Users need to be able to register/confirm their email | 
                        |  | 73 | * Users need to be able to login | 
                        |  | 74 | * When loged in users are able to view public datasets and their own datasets | 
            
                      
                        | 74 |  | * Administrators need to be able to: Authenticate users, Ban users, Delete unused accounts | 
                        | 75 |  | * Administrators are not able to register, view all,execute all | 
                        | 76 |  | * Users cannot be promoted to admin, admins cannot be demoted to users | 
                        | 77 |  | * Admins donnot register, but are 'hardcoded' into the application | 
                        | 78 |  |  | 
                        | 79 |  |  | 
                        | 80 |  |  | 
                        | 81 |  |  | 
                      
                        |  | 78 | * Administrators need to be able to: Authenticate users, Ban users, Delete unused accounts | 
                        |  | 79 | * Administrators are not able to register, view all,execute all | 
                        |  | 80 | * Users cannot be promoted to admin, admins cannot be demoted to users | 
                        |  | 81 | * Admins donnot register, but are 'hardcoded' into the application |