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
|
= Implementation of Privileges
These are some ideas for implementing the privileges system.
== Naming
The privileges will have a naming scheme that will be of a form loosely approximating the following form:
....
<top-level>:<sub-level>:<privilege-name>
....
for example:
.Example Privileges
[cols="1,5",options="header"]
|===
| Privilege Name | Description
| system:group:create-one
| Allows the holder to create only one group, of which they become a member.
Once they are a member of any group, they cannot create another. This could be
added by default for new users, and removed once they are assigned to a group.
| system:group:create-many
| Allows the holder to create more than one group. Mostly for system
administration use. This privilege will not be accessible to end users.
| group:user:list
| Allows holder to list any user in the same group as the holder, for which this
privilege is attached
| group:role:assign
| Allows holder to assign group-level roles to users
| group:resource:list
| Allows holder to list any resources for which this privilege is attached
| group:resource:view
| Allows holder to view the details of any resource for which this privilege is
attached
|===
It is important to note that *privileges are not assigned directly*, rather,
they are grouped into roles and the roles are assigned to users.
== Checking Privileges
To check privileges, a mini-DSL (Domain-Specific Language) is proposed, which
will be used to generate a checker to verify that the user has the appropriate
privileges to access a resource.
I propose a simple, lisp-like syntax that follows the form:
....
(command ...specifications)
....
where the *...specifications* is built with the *has* operator:
for example:
----
(resource-access (has "group:resource:view" "group:resource:edit"))
----
to view and edit the resource: the user has to have *all* (in this case, both)
of the `group:resource:view` and `group:resource:edit` privileges for this check
to pass.
----
(system-access (or (has "system:group:create-one") (has "system:group:create-many")))
----
to enable group creation. The user has to have one or the other of the
`system:group:create-one` or `system:group:create-many` privileges to pass.
[sidebar]
The *has-** operations acts like an *and*-ing of the privileges and thus would
be equivalent to something like
`(and (has priv1 priv2 ... privn) (has priv1 priv2 ... privm))`.
The privilege specification can be used to generate portions of queries to check
for access dependent on the type or resource in question, e.g. MRNA
Assay (Probeset), Phenotypes (Publish) or Genotypes.
The privilege specifications can also be used for checking access to system
management functions like creating groups, and modifying user details.
|
