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
|
[[!meta title="Architecture"]]
[[!toc ]]
# Architecture overview
## Assumptions
The architecture has been designed under the following assumptions:
* Privacy is important, and should be the default. People should only
have access to the information they are authorized to access.
* Members should be able to see their own information, without having
to go through the Effi membership register admin.
* It's not practical to have every member have a password.
Authentication can be done by sending the member a unique,
single-use link when they want to log in.
## Components
[[!img arch.png]]
Effireg consists of four main components:
* **effiapi** provides a RESTful HTTP API for managing the membership
data, and for doing things with or to the data. All operations on
the data go via the API.
* **effiweb** provides the frontend for the web application to use the
membership register. It renders HTML to the user, is accesses via a
web browser, and generally is the user-visible part of Effireg.
Everything effiweb does, it does by using the effiapi API. If any
other user interfaces are added (say, mobile or command line), they
will be parallel to effiweb and will also use the effiapi API in the
same way as effiweb.
* **Qvisqve** provides authentication of end-users (the members, and
admins). It lets users log in, and keeps track of what each user is
allowed to do.
* **Muck-POC** stores the actual membership register data, and
controls access to it, based on access tokens from Qvisqve.
## Authentication
[OpenID Connect]: https://openid.net/specs/openid-connect-core-1_0.html
[OAuth2]: https://oauth.net/2/
End-users are authenticated using the [OpenID Connect][] protocol,
specifically the authorization code flow. In this flow, Qvisqve
provides cryptographically signed access tokens, which identify the
user and specify a list of things the user may do. The signature
guarantees the token comes from Qvisqve.
Non-interactive API clients are authenticated using the [OAuth2][]
protocol, specifically using client credential grants. This also
provides an access token, similar to the one from end-user
authentication.
# Data model
The membership register stores data as "resources" in Muck-POC. Each
resource is a JSON object. The following types of objects are
supported:
* **subject** represents a person who is allowed to use the register;
it it used to identify the user for authentication
* **password** stores the encrypted password for a subject
* **memb** represets a subject's membership in Effi
### Subject resource
A subject resource has the following fields:
* `username` — the username of the subject; this can change, the
subject is identified by the resource identifier in the register,
not by the username
The subject resource does not have any data that isn't needed for
end-user identification. Effiapi manages and Qvisqve uses the subject
resource.
### Password resource
A password resource has the following fields:
* `subject_id` — resource id of the subject whose password this
is
* `version` — version of the password resource (identifies
algorithm); must be 1
* `hash` — the password, encrypted with the scrypt algorithm
* `salt` — a random string to prevent dictionary attacks
* `key_len` — parameter for scrypt
* `N` — parameter for scrypt
* `r` — parameter for scrypt
* `p` — parameter for scrypt
Effiapi manages and Qvisqve uses the password resource.
### Member resource (memb)
A membership resource has the following fields:
* `subject-id` — the resource id of the subject resource for
the member
* `fullname` — the full name of the member
* `primary-email` — the primary email address for the member
(and currently the only one)
* `years-paid` — list of integers for the years for which the
member has paid their membership
Effiapi manages and uses the memb resource. Effiweb renders it for the
user.
|
