1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
# Authentication/authorisation design
## Authentication
* Local database should be independent from other services and copied as a file (SQLite with JSON?)
* Later use other providers, such as gmail
* Later provide REST API & token access
### Local Authentication
This section tracks the possible flow for user authentication, specifically for users with accounts
=> /topics/authentication/user-registration registered on GeneNetwork.
* User loads login page
* User provides email and password
* If email does not exist in local database, quit authentication process with an error message, e.g. "Email or Password provided do not match our records."
* If email exist, check whether the provided password matches with the one in the database for the given password.
* If password does not match, quit authentication process with an error message, e.g. "Email or Password provided do not match our records."
* If password matches, then user has authenticated and a new session can be created.
### External Services Authentication
The system will, in the near future, allow user authentication from external services such as Git(hu|la)b, OrcID, Google (gmail), etc. The services mentioned here are just examples - there is no guarantee that any of them will be used in our system!
* User loads the GeneNetwork login page
* User clicks on link to the service they wish to authenticate with
* System redirects user to service's authentication page
* User authenticates with selected service
* If authentication fails, then the authentication process ends.
* If authentication is successful, the external service provides GeneNetwork with some token
* If it's the user's first time ever authenticating with the external service, then GeneNetwork uses the token to fetch relevant user data from the external service, and creates a local user linked to the external service
* GeneNetwork uses the data from the service to identify the relevant local user details
* GeneNetwork uses local user details to create new session
### Implementation Concerns
The passwords (and other authentication tokens) should be in a separate database table from the unifying users table. This should provide for a somewhat unifying table for the different authentication schemes that will be provided by the system.
### WONTFIX
The following features will not be considered:
* Allowing multiple login options for a single user (e.g. local, github, orcid). User will be expected to choose one and only one login option and stick with it. This will reduce complexity of the system.
## Authorisation
Once a user is authenticated they are able to access and act upon the system in the ways restricted by the authority/privileges granted to them. This section discusses the high-level details of the authorisation system used in GeneNetwork2.
### Resources
Data Resources are the "meat" of the system. They are what the users and the system act on.
* Resources will be (are) pretty flexible.
* Every data resource is owned by one, and only one group!
Examples of data resources:
* Datasets (for mRNA traits)
* Traits (for phenotype and genotype traits)
### Privileges
Privileges will be linked to roles and resources.
As will become apparent (on reading the sub-sections below), there will need to be a way to distinguish the different types of privileges to prevent accidental provision of privileges to users.
The privileges can be categorised into:
* Resource Access Privileges
* User Management Privileges
* Group Management Privileges
* Special Privileges
The sub-sections below list a number of possible privileges for each category.
#### Resource Management
* view_resource
* create_resource
* view_resource
* add_resource_data
* edit_resource_data
* delete_resource_data
* add_resource_metadata
* edit_resource_metadata
* delete_resource_metadata
* curate_resource
* transfer_resource: maybe enable tranfer of the resource to another group, losing access to it in the process.
#### User Management
These are really group-management privileges, but they can be assigned to certain non-group-leader users to help with group management.
* add_user: does not create the user; just adds an existing user, who is not a member of any group, to the group.
* remove_user: does not delete the user; just kicks them out of the group.
* create_edit_role
* delete_role: if a role is deleted, it should be automatically unassigned to any/all users in tandem.
* assign_role: assign a role to (a) user(s)
#### Group Management
These privileges are only accessible to group leaders
* create_group: the user that create a group becomes that group's "group leader"
* transfer_leadership: transfer leadership to another member in the group, losing leadership in the process
* delete_group: the group should be empty (no users, roles or resources) before deletion is possible
#### Special Privileges
These are special privileges that provide special access to the system.
These demand some bureaucracy to access due to security and privacy considerations.
* masquerade: allows a user to masquerade as another user getting the same privileges as them.
* add_self_to_group: allows a user to add themselves to a group
* assign_role_to_self: allows a user to assign themselves a particular role
### Roles
The roles will be collections of privileges that can be assigned to users. They are the system's main way of controlling access to the system and restricting user access.
### Groups
The group is the main organisational scheme for the authorisation system.
* Each group will have a group leader
* Each user in the system belongs to either no group or one and only one group
* Each group can define any number of roles to control access to their resources
EXAMPLE: A "Visitor Role" could be created to allow a user that IS NOT a member of a particular group to access (a) resource(s) that is (are) otherwise non-accessible.
### Users
Users are not really a part of the authorisation system per-se, but we do need to link the users of the system to the resources somehow (after all, that's the point of the system, to be useful to others).
Users will be linked to the resources mainly by the groups, and roles.
A user who is not a member of any group will only have access to publicly accessible resources.
## Web front-end
There will be a need for a web front-end to allow for management of groups, roles, resources and users, accessible to group leaders and their assistants (where applicable).
The privileges shall come as part of the system, and shall not be UI manageable. Any changes to the privileges shall require a system redeployment.
## Other Implementation Concerns
* Local database should be independent from other services and copied as a file (SQLite with JSON?)
* Later provide REST API & token access
## Some Related Issues
The following issues are related to this topic.
=> /issues/authorisation Clean Up Authorisation (contains extra info)
=> /topics/authentication/replace-hard-coded-auth-with-gn-proxy Replace Hard coded authentication with gn-proxy
=> /topics/authentication/user-info Put user info in the a/c name in the menu
=> /issues/authentication_authorisation/migrate-user-accounts-from-redis Migrate User Accounts from Redis to new Auth DB
=> /issues/authentication_authorisation/build-oauth2-client-registration Build Registration Page for OAuth2 Clients
|
