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
|
# OAuth2
The new authorisation system is made up of two layers:
* Client authorisation
* User authentication/authorisation
This document will concern itself mostly with "Client Authorisation".
## Client Authorisation
The authentication/authorisation system will (probably) find use in the entire
suite of applications that are under the Genenetwork umbrella.
The relevant applications (as of 27 May 2023) are:
=> https://github.com/genenetwork/genenetwork3 Genenetwork3
Serves as both the authorisation server and the API server.
=> https://github.com/genenetwork/genenetwork2 Genenetwork 2
Will eventually be the main user-facing UI making requests to GN3 for data and computational requests.
=> https://gitlab.com/fredmanglis/gnqc_py QC and Data Upload
Provides a means to upload new data into the Genenetwork database. It does perform some quality-control on the data before upload. Currently, this application is not available to the general public due to the potential to mess up the data. Once the auth system has been running a while, and the major bugs quashed, this will be integrated into the other system and allow users to upload their own data.
In this case, the GN2 and QC applications would be clients to GN3 (as the auth
server), and will have specific scopes of access.
As such, we need to register the clients that can access the authorisation
server.
If you try to access the authorisation server, or for that matter, the API
server with a client that is not registered, you will receive an error message
of the form:
```json
{
"error": "invalid_client",
"error_description": "No client found for the given CLIENT_ID and CLIENT_SECRET."
}
```
### Registering a new OAuth2 Client
To enable the clients (such as GN2 and QC mentioned above) to work with the authentication and/or API server (GN3), we need to register them. We do that on GN3, and only an administrative user has that ability.
The administrative user logs on to GN3 on the `/api/oauth2/admin/login` endpoint. Once logged on, they can visit the "Register OAuth2 Client" page on the `/api/oauth2/admin/register-client` endpoint. There they can provide the necessary information, and select from a set of options that apply to the client they are registering.
Once the admin submits the registration information, the system will generate CLIENT_ID and CLIENT_SECRET values and show them. The CLIENT_SECRET value is stored encrypted in the system and there is no way to retrieve it once the user navigates it away from the registration page.
The CLIENT_ID and CLIENT_SECRET values are then added to the client's (e.g. GN2) configurations to enable the client access the servers.
## User Authentication/Authorisation
A user will make use of (an) authorised client(s) (see 'Client Authorisation'
section above) to access the authorisation and API servers.
Once the user has authenticated (provided valid authentication credentials),
they will be able to access the resources in the system according to the roles
and privileges that they are authorised for.
|
